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

I like the idea of treating these path expressions as shortcuts for 
conjunctions of frames.

The problem is that Christian's proposal is a shortcut for conjunctions 
of the "singleton slot frames" that he proposed at F2F12.
E.g. ?x[attr=val] has shortcut ?x.attr=val, but ?x[attr->val] has no 
defined shortcut.  (For the record, I would propose ?x/attr=val).

I'm not strongly opposed to ?x[attr=val] and its shortcut ?x.attr=val.  
PRD clearly needs something like this (I suspect it also needs to test 
for null, e.g. ?x.attr=null, to support 0..1 slot values.)  The problem 
is, cardinality constraints on frame slots is not in Core.  Maybe it 
should be the logic dialect community's "problem" to add this to Core in 
order to interoperate with PRD rather than be PRD's "problem" to try to 
live without it...

Michael Kifer wrote:
> 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 Tuesday, 3 March 2009 07:28:06 UTC