Sugar unrelated to macros -- Was: Re: Sugar

Ingvar von Schoultz ingvar-v-s at
Sat Aug 30 17:23:58 PDT 2008

Dave Herman wrote:
 > Brendan Eich wrote:
>> But a more complete proposal would be  
>> needed to be sure. I was making a few assumptions from the examples.
> Agreed, especially Re: the effects it would have on the parser.

Unfortunately I'm not sufficiently competent about the subject
to evaluate the effects on the parser.

Maybe I should mention that if it's important for the compiler,
the desugaring of multiple-keyword expressions can use a much
simpler strategy:

     use sugar a, b, c, d, e;
     a b c Name (...) d e new Parent (...) {...};

might desugar into:

     a (b (c (function Name (...) {...}, d (e (new Parent (...))))));

The desugaring that I showed in the thread starter is very likely
not the best, I chose that mainly because it helped make the
explanation clear.

In many aspects of this proposal, many variations are possible,
with different tradeoffs. I think it would be a good idea to let
it mature step by step while discussions evolve.

Speaking of completeness, the sugar functions need more information.

     use sugar word;
     word Example (x)
     {   ...

might be desugared into this:

     const Example = word
     (   this,
         function() {return x},
         function Example (x)
         {   ...

Passing |arguments| would allow control-structure keywords better
functionality, but it would break encapsulation and undeprecate
|arguments|, so it's very debatable.

If the Ruby blocks that Chen is proposing should become available,
the above problem would disappear.

If there are no Ruby blocks, then in compensation the desugaring
might be expanded to detect and propagate return statements when
applicable. But that's worthwhile only if people will use control-
structure keywords, or other keywords where such a functionality
is desirable.

Another issue is the fact that classes are data types.

So it all depends on many things, and should probably mature gradually
as discussions evolve.

Ingvar von Schoultz

More information about the Es-discuss mailing list