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

On Tue, 03 Mar 2009 14:40:01 +0100
Christian de Sainte Marie <csma@ilog.fr> wrote:

> Michael,
> 
> Michael Kifer wrote:
> > 
> > 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.
> 
> I must not have been clear about it: my proposal is about the representation
> of single-valued attributes, as is usual in object-oriented programming.
> 
> Or is your point that my choice of the point-based path notation for the PS
> in my strawman proposal is confusing, because that notation is also used in
> contexts where the expressions are not necessarily single valued?

Yes. This particular syntax clashes with other known uses (which might be used
in other rif dialects later).

> If this is the case, I have no problem using a different PS, or keeping only
> the XML syntax :-)
> 
> It is like for the name of the construct (Getter): we can certainly find a
> better name and PS. But I would rather not waste our time finding them,
> before there is at least some consensus that we want to have such a
> construct.
> 
> > Regarding your puzzle ?x[attr->?x.attr], it is a shortcut for
> > ?x[attr->?y] /\ ?x[attr->?y].
> 
> No, sorry again for not having been clearer: it is not. Because in my proposal, ?x.attr is explicitely single-valued.
> 
> The PRD2Core fallback from: P(?x.attr) (where ?x.attrr is a single valued
> basic term according to my strawman proposal) to: Exists ?y (?x[attr->?y /\
> P(?y)) (where  the number of values of the "attr" slot in the frame is not
> constrained) works because there is no fallbacks for other PRD constructs
> that require the "single-valuedness" of the attribute "attr": so, the change
> is neutral if no such construct is used in the rules; and, in all the cases
> where the change risks not be neutral, that is, when a
> "single-valuedness"-requiring construct is used, the ruleset will be rejected
> as not PRD2Core-ifiable.

This is correct. Whether you use some kind of path expressions of a different
form for single-valued attributes is a matter of personal preference.


> ?x[attr->?x.attr] (where, again, ?x.attr is a single valued basic term, per
> my strawman proposal) is trivially true when the (single) value of ?x.attr is
> an individual or a literal. The question I had in mind when I used the
> shortcut ?x[attr->?x.attr], is when the (single) value of ?x.attr is, e.g., a
> set.
> 
> But the benefit of having a specific syntax for the single-valued attributes
> is that we do not have to specify the equivalence with other, existing
> constructs, such as the frame. Or should I rather say: the motivation for
> having a specific syntax for the single-valued attributes is that we do not
> have/want/know how to specify the equivalence with other, existing
> constructs, such as the frame?

It is not clear to me whether you want this syntax to be in Core or just in
PRD. If the latter then things would be vastly simpler.

> > If you are treating x.attr procedurally then you might get into trouble.
> 
> Do you mean, in your acceptation of ?x.attr (not necessarily single-valued),
> or also in my strawman proposal (where it is single-valued by definition)?

No, I just thought that if you interpret ?x.attr procedurally and if ?x.attr=?y
is a synonym for ?x[attr->?y] then there seems to be an infinite loop somehow.
But maybe you have a different notion of invocation and the problem does not
arise.

To me, a procedural meaning of ?x[attr->?x.attr] seems to be computing attr for
?x, and in order to compute that one needs to compute ?x.attr (which is the
same), etc.

michael

> 
> If the latter: that would, indeed, be a rather big drawback; maybe to the
> point of making my proposal useless. Can you explain?
> 
> Cheers,
> 
> Christian
> 
> 
>

Received on Tuesday, 3 March 2009 18:24:54 UTC