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

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.

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. 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 ...

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...

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?

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.

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
>

Received on Tuesday, 10 March 2009 18:06:19 UTC