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

On Tue, Mar 10, 2009 at 11:05 AM, Christian de Sainte Marie <csma@ilog.fr>wrote:

> Gary Hallmark wrote:
>
>  A variable can represent many values.  E.g.
>>
>> ex:a(1)
>> ex:a(2)
>> forall ?x if ex:a(?x) then ex:b(?x)
>>
>> ?x is 1 and 2.
>>
>
>
> Yes, of course, a variable can be bound to many different values; but when
> it is bound, it is bound to a single value.
>
>  Path expressions are just a shortcut for a variable.  E.g.
>>
>> if _obj.slot > 2 and _obj.slot <= 5 then ...
>>
>> is short for
>>
>> forall ?z if _obj[slot->?z] and ?z > 2 and ?z <= 5 then ...
>>
>
>
> Yes, I understand that this is what Michael means, and this is what I have
> some difficulty with.

Our understanding is somewhat different, I think.

>
>
> If obj.slot is multi-valued, you can write, e.g.
>
> (1) FORALL ?obj, IF ?obj.slot = 1 AND ?obj.slot = 2 THEN ...
>
> and the the condition is not trivially false.

I think it is false.

> Like you would write
>
> (2) FORALL ?obj, IF EXISTS ?y, ?z, ?obj[slot->?y] AND ?obj[slot->?z] AND ?y
> = 1 AND ?z = 2 THEN ...

 That's not my intuition of the meaning of the path expressions.  Mine is
FORALL ?obj, ?val IF ?obj[slot->?val] AND ?val = 1 AND ?val = 2 THEN ...


>
> But this is not how it is used in most object-oriented programming
> languages, nor in OCL, where obj.slot represent the single value that the
> field "slot" of object "obj" holds a the time of evaluation. Of course, that
> value can be any value, and obj.slot can take many values over time. What I
> meant when I said it was single-valued is that, at any given time, it had
> one single-value.
>
> So that rule (2) would rather translate into something like:
>
> (3) FORALL ?obj, IF (1 in ?obj.slot) AND (2 in ?obj.slot) THEN...

I'm  assuming that ?obj.slot is a single variable.  Maybe you mean

 FORALL ?obj1, ?obj2, IF ?obj1=?obj2 AND ?obj1.slot = 1 AND ?obj2.slot = 2
THEN ...
Clearly this is not trivially false.

>
>
> where obj.slot would be (single) set valued.
>
> The problem I have with obj.slot being multi-valued is that, unlike
> obj[slot->value], where you can have obj[slot->value1], ...,
> obj[slot->valuen] being all true at the same time, obj.slot is not a fact.
> It is, well... a value, and that is where I am trapped:  if it represents a
> value, of course, it has to represent a single value; and if it is not a
> value, what is it?

I think it is clearly a variable.

>
>
> But that discussion may be beside the point: what if we added a basic term
> of the form objID+slotID, with whatever PS we can agree on, and with the
> understanding that, as a basic term, it represents a single value. That is,
> just what I proposed initially.

It's not the presentation syntax that is at issue.  The issue is what it
means. Michael and I say it is merely a shortcut for not having to introduce
a rule variable and bind it with a frame formula.  This doesn't magically
make frames single valued.  If you want single valued frame slots, then we
should add a constraint somehow on the existing frame slots.  Then, as an
orthogonal issue, if you want to add path expressions then they should work
for both single and multi-valued frame slots (although you might use
obj.slot as shortcut for a variable bound to a single valued slot, and
obj/slot as a shortcut for a variable bound to a multivalued slot)

>
>
> And that would be how we would by-pass the issue of single-valued
> attributes.
>
> And regarding the issue of compound location path, we could deal with it
> separately, allowing TERM+slotID for the new basic term (and thus, compound
> location pathes), for representing values; as well as nested frames:
> TERM[slot->TERM|Frame] for facts.
>
> Would that work?
>
> Cheers,
>
> Christian
>
>>
>>
>
>


-- 
Cheers,

Gary Hallmark