Re: [PRD] Proposal for object representation (and ACTION-592 complete)

Christian,
these things are called path expressions and they are not necessarily
single-valued. For instance, FLORA-2 uses them alongside the frames,
and they are simply shortcuts for some forms of conjunctions of frames.
Regarding your puzzle ?x[attr->?x.attr], it is a shortcut for
?x[attr->?y] /\ ?x[attr->?y].
If you are treating x.attr procedurally then you might get into trouble.

michael

On Mon, 02 Mar 2009 18:52:43 +0100
Christian de Sainte Marie <csma@ilog.fr> wrote:

> All,
> 
> I completed my ACTION-592, and opened ISSUE-94 on the RIF representation of objects' attributes and methods.
> 
> I also have a proposal to reslove the issue, btw :-)
> 
> My proposal for dealing with object would be to extend PRD terms (BLD basic terms) to include a construct to represent the value of an object member (attribute or method); that is, instead of adding a frame-like atomic formula for single-valued attributes.
> 
> That would add another kind of TERM, in addtion to the Const, Var and External function call (and Expr for uninterpreted functions, in BLD): in the following, I call it a "Getter", but it is probably not very difficult to find a better name.
> 
> The essential idea is that, as a term, it has one single value, and that it is compatible with the frame, too. 
> 
> To represent a Getter, one needs to represent the "object" (from which the value is got) and the "member" (that indicates how the value is got from the object). The object is represented by a TERM and the member is represented by a "Const" or "Expr", depending on whether the value to be got is assigned to an attribute of the object, or whether it is returned by a method of the object. The presentation syntax could look like (see also attached diagram):
> 
>  TERM           ::= IRIMETA? (Const | Var | 'External' '(' Expr ')' | Getter)
>  Getter         ::= TERM '.' (Const | Expr)
> 
> And the XML syntax:
> 
>  <Getter>
>    <object> TERM </object>
>    <member> [ Const | Expr ] </member>
>  </Getter>
> 
> Assume, for instance, that a variable ?p is bound to an object of the class person: 
> 
>  CLASS Person
>      Integer : age
>      Person : spouse
>      Person : childFromSpouse(Person : child)
> 
> where childFromPreviousSpouse is a method that takes a Person as its single argument and that returns the Person with whom ?p had the child bound to ?ps.
> 
> ?p.age is a Getter, with TERM: ?p the object and Const: age the identifier of the field;
> ?p.spouse.age is also a well-formed Getter, with Getter: ?p.spouse the object and Const: age, again, the identifier of the field;
> and ?p.childsFormPreviousSpouse(?ps) is a Getter as well.
> 
> Such a Getter TERM would allow atomic condition elements such as: ?p.age > 18, etc.
> 
> In PRD, we would need to add a "setter" action: Set(Getter, TERM), that would replace the value of the first argument (the Getter) by the value of the second argument. 
> 
> And, btw, we could then restrict the intitialization part, in the declaration of an action variable, to be a TERM, thus avoiding the ambiguity of allowing (multi-valued) frames. That would make "New" a TERM, too, btw, which makes sense...
> 
> Finally, it is compatible with Frames, as far as I can see. At least, there is an easy fallback to Frames in Core (if Core does not add the Getter as well), since a Getter obj.mem in a expression can always be replaced by a variable and the expression wrapped inside an existential quantifier for that variable, and conjoined with a Frame that cpnstrain the bonding of the variable. E.g.:
>  ?p.age > 18
> would fallback to
>  Exists ?a (?p[age->?a] AND ?a > 18)
> 
> Of course, we would need multiple existential variables for chained fieds:
>  ?p.spouse.age > 18
> would give
>  Exists ?s (?p[spouse->?s AND (Exists ?a (?s[age->?a] AND ?a > 18)))
> 
> Of course, that does not truly address the relationship betweem Frames and single-valued attributes in objects (e.g. whether ?x[attr->?x.attr] etc), but that is probably out of RIF's scope, anyway.
> 
> Notice that the above proposal does not cover the use of boolean methods as condition elements in rule conditions: that would require to add an (external) atom equivalent of the Getter, restricted to the TERM.Expr syntax.
> 
> Discussion?
> 
> Cheers,
> 
> Christian 
> 
> 
>

Received on Monday, 2 March 2009 18:08:00 UTC