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