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
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss

--
Alex Russell
[email protected]
[email protected]
[email protected] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to