[e-lang] On kernel-E, operators, and properties

Mark S. Miller e-lang@mail.eros-os.org
Mon Mar 15 03:00:54 EST 2004


At 11:30 PM 3/12/2004  Friday, Constantine Plotnikov wrote:
>John Williams wrote:
>>I *think* what Constantine is saying is that there should be a special class of identifiers used only for operators and acessor methods that would not obey the normal rules for identifiers. So for instance, the addition operator would map to "operator+/1" instead of "add/1". The parser would of course have to be changed to accomodate the new identifiers, either by accepting "operator+" as an identifier, or (as in C++) by adding the keyword "operator" and allowing the two tokens "operator" and "+" in places where an identifier is normally used.
>>
>>This has the advantage that method names like "add" would then be free for things that shouldn't map to the "+" operator, such as appending items to a list, or addition in place. Also, nobody would have to remember which name corresponds to which operator ("Is the subtraction operator called 'subtract' or 'minus'?").
>
>Yes. This is an idea for operators.

First, to repeat the bad news announced at 
http://www.erights.org/download/0-8-26/highlights.html#fetch :

>We are not going to be making the agreed operator renamings 
>http://www.eros-os.org/pipermail/e-lang/2002-June/006750.html , because I 
>don't know how to do it and repair our code base in a reasonable time 
>frame. Therefore, "m[argsList,...]" continues to expand to 
>"m.get(argList,...)". This is problematic for all the reasons mentioned in 
>these threads 
>http://www.eros-os.org/pipermail/e-lang/2001-April/005069.html , but we can 
>live with it. 

Were we to change the selectors the operators expand to, I don't see the 
advantage of, for example "operator+" over "op__add". While I do see the 
advantage of both over "add", sadly, as stated, I don't know how to do this, 
and recover quickly. The problem isn't the senders of the old names -- the 
problem is the implementors, including many legacy Java implementors. At the 
least, we probably need to extend the .safej taming mechanism with a 
renaming construct.

If anyone thinks they can do this renaming and repair in a timely manner, 
I'd be overjoyed to incorporate your changes. Otherwise, despite my earlier 
promises, I'm going to have to say this attractive change just didn't make it.

Nevertheless, I understand the need to support message names (i.e., 
selectors, verbs) other than E identifiers. In fact, E already does use such 
non-identifier verb strings to specify which Java overload to invoke (see the 
section "Speaking to Java objects with superclass/subclass overloaded 
methods" at http://www.skyhunter.com/marcs/ewalnut.html#SEC14 ). The 
existing E.call/3 allows such messages to be sent, and the optional match 
clause in an object definition reifies the verb of the incoming message, 
allowing further dispatch by user-written code. But these solutions are, 
perhaps, unnecessarily awkward.

To experiment with an alternate means for allowing E code to use 
non-identifier verbs, in order to better bind to legacy libraries whose 
message names include non-E identifiers (such as Squeak), the upcoming 
0.8.26h introduces the "e.enable.verb-string" experimental syntactic 
feature. When turned on, anywhere the syntax accepts an identifier as a 
verb, one can instead use a literal quoted string:

    ? pragma.enable("verb-string")

    ? def foo {
    >     to "+"(x) :any { return 3 + x }
    > }
    # value: <foo>
    
    ? foo + 4
    # problem: <NoSuchMethodException: <a foo>.add/1>
    
    ? foo."+"(4)
   # value: 7

One could as easily use the string "operator+" above.

As always, unless stated otherwise, features that must be explicitly enabled 
are not part of the official definition of the E language, and we make no 
commitment to continuing support of such features. 


>For properties, I would like them to be first-class constructs rather then 
>expansions like it is now. In .NET and Java properties have  method names 
>generated. And in .NET creation of property for pair of get_Prop and 
>set_Prop methods is not automatic. There should be an explicit property 
>member in the class.
>
>It could be done as new syntax construct as I have originally proposed or as 
>pair methods with some special names as John Williams proposes.

If they are a pair of names, then it would seem to me they are still 
expansions, which at least I understand. If they are not expansions, what 
are they? Would the existing caretaker pattern successfully forward and 
revoke property access? If not, would they be a means of inter-object 
causality other than messages?


Since "e.enable.dot-props" is still turned off by default, E currently has 
no built in notion of property. Instead, the only such issue we currently 
face is how to map Java field names (both static and instance) into E verbs. 
For this, we are using the Java property-name mangling convention:

    "foo" -> "getFoo()" / "setFoo(newValue)"

This does collide with the case vs internationalization issue Kevin and 
Danfuzz raise:

At 09:09 AM 3/8/2004  Monday, Dan Bornstein wrote:
>Kevin Reid wrote:
>>Against dot-props: [...], involves a transformation of
>>identifiers ("foo" => "getFoo") (which complicates textual
>>searching of unexpanded source code) [...]
>
>Another thing to be aware of in the territory of name transformation
>is that capitalization rules depend on your locale. The easy case to
>point out is that in Turkish, the letter "i" when capitalized
>doesn't turn into "I" but rather to U+0130 ("LATIN CAPITAL LETTER I
>WITH DOT ABOVE").
>
>This is also, btw, the compelling case for why filesystems ought not
>be case-insensitive at their lowest layers.

Since our purpose is binding to Java, we use the Java convention: For better 
or worse, we capitalize according to Character.toUpperCase(c), which is 
locale independent. See
http://www.erights.org/javadoc/java/lang/Character.html#toUpperCase(char)


-- 
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM




More information about the e-lang mailing list