optional "function" keyword

Herby Vojčík herby at mailbox.sk
Sat Mar 10 02:26:34 PST 2012

Brendan Eich wrote:
> Herby Vojčík wrote:
>> Herby Vojčík wrote:
>>> Possible Smalltalk-inspired precedent is also:
>>> (:x, y) x+y
>>> (:x) (:y) "z"
>>> (:x) (y) "z"
>>> (:x) (y) (z)
>>> I think I like this most...
>>> Herby
> We've talked about these variations, but they all seem grawlixy or worse
> (the C++ pre-11x bug with template instantiation nesting where you have
> to put a space between > and > to avoid writing a right-shift operator).
> I agree this one is nicer but it's still grawlixy, or emoticon-y ;-). It
> does avoid the ambiguous grammar worry, on the up side.

Well, I just wanted easy way to retain familiar '(params) expr' syntax, 
but to use something lightweight (not % or @ or something like it) to 
disambiguate it so to make parsing it possible.

Dot is even more lightweight, but maybe could look grawlixy to many, too:

   (.x) (.y) "z"
   (.x, y) x+y

or maybe better

   .(x) .(y) "z"
   .(x, y) x+y
   shortFoo .(bar) bar+1

(though, if parenfree Russell's one could get in, it would probably be 
help more, there is many parens already)

> The fat-arrow, =>, is better, and it can be made to work if we figure
> out and agree to pay for the spec-grammar validation against ambiguity
> work.
>> Maybe this could even be competely paren-free (tell me where it breaks):
>> :x, :y x+y
>> :x :y "z"
>> :x (y) "z"
>> :x (y) (z)
>> Imagine the code like coll.map(:x x*x) or coll.filter(:x x%2==1).
> Formal parameter list syntax should include all the bells and whistles
> (rest parameter optional at end, paramater default values for trailing
> formals, destructuring patterns) so we should be conservative.

Is this the problem of Russell's
   :x, y => x+y
as well?

> One-parameter paren-free special casing, as in C#, is plausible.
> x => x*x
> (x,y) => x*y

I do not like special cases much.

> Thanks for throwing out alternative syntaxes. We should keep beating on
> this anvil, shorter function syntax is well worth it. But we need a
I am doing it now.
> non-GLR parsing procedure that rejects ambiguous grammars.
> /be


More information about the es-discuss mailing list