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

