simple shorter function syntax
Alex Russell
alex at dojotoolkit.org
Fri Jul 23 10:32:37 PDT 2010
Oliver's right (as usual). Erik and I talked through alternatives like "f" before proposing "#", and the other constraint not mentioned yet in the thread is typability. Yes, "#" requires a shift key on US keyboards, but it's not any harder than that on dvorak and european layouts. "#" (or something like it) seemed a good tradeoff.
On Jul 23, 2010, at 10:27 AM, 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.*
>
> 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
--
Alex Russell
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
More information about the es-discuss
mailing list