[e-lang] On kernel-E, operators, and properties (part 2)

[David Hopwood]

Mark Miller wrote:
> At 03:04 PM 8/2/2004  Monday, Kevin Reid wrote:
>>On Aug 2, 2004, at 14:50, Mark Miller wrote:
>>
>>>http://www.erights.org/download/0-8-30/highlights.html#new_features
>>
>>>Finally, 'foo::&propName' expands directly to 'foo.__getPropertySlot("propName")'
>>
>>What is the advantage of foo::&bar over &foo::bar?
> 
> I just found it in the archive! 
> http://www.eros-os.org/pipermail/e-lang/2004-April/009719.html

That reminds me, I never got around to "part 2" of this post. Part 2 was going 
to be about a generalisation of slots -- basically allowing a slot to refer
to a set of possible values -- in order to support Oz-style constraint
programming.

This would also have unified types and constraints along the lines described 
in http://www.eros-os.org/pipermail/e-lang/2003-August/008941.html .
(I found a way to fix the "it is possible for a program to work by accident"
and "loosening a type declaration can change the behaviour of a correct
program" problems listed under "Cons:".)

I've decided that this needs more work, and that I don't know enough about
constraint programming yet to make a more concrete proposal, but I definitely
intend to return to this subject at some point.

Getting back to simple slots, my earlier post proposed the following
expansions, in addition to the ones corresponding to new features of E 0.8.30:

    expr1<-name := expr2  -->  expr1<-&name<-setValue(expr2)
    expr<-name            -->  expr<-&name<-getValue()
    expr<-&name           -->  expr<-__getPropertySlot("name")

(i.e. referring to a property of an object in a remote vat). This syntax is
no longer right, because property names are now effectively in a different
namespace from method names, but I think that a syntax for this would still
be useful.

Maybe one of
    expr<::name
    expr<-::name
    expr::<-name
?

As explained in http://www.eros-os.org/pipermail/e-lang/2004-April/009720.html
the slot object for a given property must not change. Does the documentation
for __getPropertySlot say that?

I agree with the __makeVerbFacet changes.

Also, you asked the following question:
 > So let's turn this into a related question about E's vanilla mutable
 > collections, FlexList and FlexMap. Both of these support the
 > 'collection[key]' syntax as both an lValue and an rValue. This suggests
 > that we may also want to somehow support the syntax '&collection[key]'.

In the constraint proposal mentioned above, being able to access the
slot of a collection element would be important because it would allow
collections of partially determined values. FlexList and FlexMap would
be maps from indices/keys to slots, using some additional method such
as "__getSlot(key)". This can be added compatibly, so there's no need to
change anything now.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>