"Syntax for Efficient Traits" is now ready for discussion (was: Classes as Sugar is...)

Mark S. Miller erights at google.com
Mon Sep 13 17:27:16 PDT 2010


On Mon, Sep 13, 2010 at 5:18 PM, Oliver Hunt <oliver at apple.com> wrote:

>
> On Sep 13, 2010, at 2:02 PM, Mark S. Miller wrote:
>
> On Mon, Sep 13, 2010 at 1:18 PM, Dmitry A. Soshnikov <
> dmitry.soshnikov at gmail.com> wrote:
>
>>
>> I didn't finished a detailed reading yet, but from the brief scanning,
>> syntactically, I think *=>* and *trait class* are not needed.
>>
>
> * I used "trait class" rather than "trait" for two reasons:
>
>     1) Syntactic ambiguity fear. "trait" is not one of the identifiers
> reserved by ES5 or ES5/strict, and so I am not proposing that it be an
> ES-Harmony keyword.
>
>     2) More importantly, the object binds to the name it declares is not a
> trait but a function for making traits.
>
>
> I'd prefer 'class trait' which i think reads better, but i'm not sure how
> much i'm biased due to my desire to retain LL(1)-ness (I know that there is
> _some_ bias at least)
>

Given that we're not treating "trait" as a keyword, when we see

    class trait(x, y) => {...}

how would we know whether this is an anonymous TraitClassExpression on a
named ClassExpression for the class named "trait"? I agree we could make a
special case for "trait" appearing in that position, but is that more or
less unpleasant that the lookahead needed to distinguish "trait class"?

Also, to my ears, "trait class" reads like "adjective noun". A "class" is a
thing for making the kinds of things it describes. A "trait class" is a
thing which makes the traits it describes. For the same reason, several
people have suggested "const function" and no one has suggested "function
const".


>
> --Oliver
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100913/499e185b/attachment.html>


More information about the es-discuss mailing list