[e-lang] Bug: Non-composability of __getPropertySlot

Mark S. Miller markm at cs.jhu.edu
Sat Jul 22 21:50:25 EDT 2006

This is in reply to old e-lang message
In this case, I'm only quoting the immediately relevant parts. Please see the 
original for more context.

Kevin Reid wrote:
>>> Consequence #2.2:
>>> Additionally, this makes non-simple accessors in E code more  
>>> difficult to write, unless we add sugar.
> ...
>>>     to &size() {
>>>       return def sizeSlot {  # has to invent a name for it, or use _
>>>         to getValue() { return _primArray.getSize() }
> ...
>>> Consequence #2.4:
>>> If neither unary-star nor dot-props is enabled, #2/#3 make accessing  
>>> ordinary properties much more complicated.
>>> Before:
>>>   foo.getBar()
>>> After:
>>>   foo.&bar().getValue()
> ...
>> [...] My sense
>> is that, although this proposal results in a simpler overall language, 
>> #2.2 & #2.4 show that it results in a steeper learning curve. For 
>> language adoption, getting started quickly and learning by simple 
>> incremental steps is probably more important than overall simplicity.
> I believe the right fix for #2.2 in this proposal is to introduce 
> property-definition sugar. #2.4 is conditional on the *lack* of dot-props.

I continue to subscribe to my comment above: For now, I want to avoid 
introducing the property concept into the official E language as anything more 
than a convention, in order to reduce the number of concepts that need to be 
explained. However, I have also come to better appreciate why we may want to 
introduce some more official support, such as syntactic sugar, later. Let's 
keep experimenting on this on the side, but let's settle on a first official E 
language without this.

To the extent that we can anticipate what will be required for future property 
support, we should warn that such changes might be coming, such as a new 
Miranda method.

This raises the issue of versioning E. E programs have a way to sense what 
version of E they're running on:

     ? interp.getProps()["e.version"]
     # value: "0.8.37a"

Should E programs have a standard way to declare what version of E they're 
written in? HTML documents do, and, at least at one point, BitC did. In 
E-on-Java, there's currently some mechanisms intended to support a declaration 
such as


This would load (from the CLASSPATH, which is in E's TCB) the resource
which would contain settings for the same switches that are also controlled by 
pragma.enable/1 and pragma.disable/1. When code declared as written in version 
X is run on E version Y, the only operational effect of the declaration would 
be to effect how it expands to Kernel-E version Y. Post-expansion, all code 
running on E version Y is running according to version Y's semantics. I think 
this would strike a good balance between supporting the past and fixing the 

>> Tentative bottom line: I think we should get rid of the notion of 
>> "properties" as a part of E supported by special mechanisms. This 
>> means we should reject the experimental "::" syntax. We should also 
>> deprecate and quickly kill the __getPropertySlot/1 Miranda method. All 
>> this was part of a worthy experiment, but it just didn't work out.
> If we do this, I would prefer that we use a different naming scheme than 
> getFoo, because of the case-smashing. Even if the E language itself has 
> no code which creates and disassembles property names, there will still 
> be programs which generate objects having idiomatic interfaces, and 
> attempt to interpret the idioms of other objects.

Although it has problems, I'd like to keep the getFoo convention. The main 
problem I've personally encountered with it is when an object wants to provide 
an accessors for getting its Foo guard or auditor. If this method were named 
getFoo, it would imply that we're getting something we'd describe as a "foo" 
rather than a "Foo". What I think I've done on these occasions is simply to 
call the accessors getFooGuard or some such. Clear enough perhaps to a human 
reader, but unfortunately irregular enough as to give trouble to software.

Perhaps GetFoo for such cases? Yuck; but I have no better suggestion.

> My current work on E-on-CL is to give it its own parser (based on Dean 
> Tribble's ANTLR grammar for E) and Kernel-E expander instead of 
> depending on E-on-Java for those subsystems.
> Once Dean Tribble and I have this working, I intend to experiment with 
> various property-access systems, such as the slot-getter sugar I mention 
> before, to see what actual usage would look like.

I'm glad you're experimenting with this. I do think we'll need something like 
this eventually.

Text by me above is hereby placed in the public domain


More information about the e-lang mailing list