simple shorter function syntax

[Dmitry A. Soshnikov]

On 23.07.2010 21:27, Oliver Hunt wrote:
> On Jul 23, 2010, at 10:08 AM, Trans wrote:
>
>    
>> Hi--
>>
>> I was reading about the proposed shorter function syntax on the wiki
>> and want to comment on it.
>>
>>   http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
>>
>> I do not see how it is advantageous to using a special symbol, '#'.
>>
>> Taking the example.
>>
>>   [0, 1, 2, 3].map( #(x) {x * x} )
>>
>> If the goal is just to be more concise, what is wrong with 'f' as an
>> abbreviation of 'function'?
>>
>>   [0, 1, 2, 3].map( f(x) {x * x} )
>>
>> Or 'fn', if it seems a little clearer.
>>
>>   [0, 1, 2, 3].map( fn(x) {x * x} )
>>
>> Heck you could even use 'y' as an upside down lambda if you wanted.
>>
>>   [0, 1, 2, 3].map( y(x) {x * x} )
>>
>> Any of these seem a much nicer choice than '#', IMHO.
>>      
> This would require an LL(infinity) grammar as you get ambiguity between a function call and a lambda declaration -- this is solvable with an LALR parser but at substantial performance cost, and in general LALR parsers require a secondary tree walk to validate code in strict mode.  Just using an LALR vs LL parser is a very easy way to more than double the time it takes to parse stuff, and that's without all the other optimisations we can do if we know we don't need to look at the full parse tree after validating the input.*
>
>    

Excuse me, can you clarify (I don't know LL, LR grammar parsers work 
well), but it's just interesting:

What the difference between the following two cases, and what the issue 
of the "LL(infinity) grammar" for the second one?

[1,2,3].map(function (x) { return x * x }); // current implementation, 
or even with exp.closures function (x) x * x

[1,2,3].map(fun(x) { x * x }); // suggested which will cause 
"LL(infinity) grammar" issue

P.S.: in general, I'm not against #, as I said, it's possible to get a 
habit for it quickly. But, just interesting about "issues" of "fun" and 
other readable variants.

Dmitry.

> Additionally I suspect that this syntax would behave awkwardly in the presence of automatic semicolon insertion, eg. is
> f(a)
> {...
> a function call followed by an open block, or is it a function declaration?  I also suspect that there's plenty of minified code that's perfectly happy to plant something like
> f(foo) { ... }
> which would be broken by such a change.
>
> --Oliver
>
> *  To give you an idea of how important parsing is, the 280 North folk once told me that parsing made up 25% of the load time for 280 Slides.
>
>    
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>      
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>