simple shorter function syntax

[Dmitry A. Soshnikov]

On 26.07.2010 18:44, Dmitry A. Soshnikov wrote:
> 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
>

I didn't even consider the fact that "fun" won't be a keyword in 
discussed variation of proposal (@ohunt clarified on Twitter). Then of 
course the parser ambiguity is understandable.

But I don't think I'd like the language where "fun" may be a variable 
name and at the same time create a function (of course if "fun" isn't a 
keyword in such system). How was such system considered at all then? Of 
course "fun" in my misunderstanding was a keyword. Actually, ES5 already 
has such case, when a keyword - is normal identifier name, but because 
of e.g. "function" is a keyword there is no ambiguity:

this.function = function() {}; // global "function" function

this.function(); // OK
function(); SyntaxError, there's no LL(∞) problem, of course

Dmitry.

> 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
>