Function Syntax
Brendan Eich
brendan at mozilla.com
Tue May 10 18:07:51 PDT 2011
On May 10, 2011, at 4:53 PM, Douglas Crockford wrote:
> The language has difficult syntax due to its C/Fortran heritage which daily
> makes the use of the language unnecessarily painful. I would like to repair
> the traps and confusions so that the language can be practiced more
> productively. Brendan says that that ship has sailed, or sunk,
No, I have a proposal, IIRC you liked it:
http://wiki.ecmascript.org/doku.php?id=strawman:paren_free
It also allows us to clean the for-in slate so ' for v in [1, 2, 3] {...}' iterates over the values 1, 2, and 3.
> but I think
> introduction of expressive function syntax gives us some license to reconsider
> some things.
Definitely.
> Some of the proposals and wishes for new syntax are alarming, in that they
> appear to be increasing the problem set, rather than reducing it. For example,
> the language has a confusion between blocks and object literals. Any new syntax
> should reduce or eliminate this confusion, not amplify it.
Working on that. I'll mail when the http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax page has been upated.
> I see this design problem as an intricate puzzle. There are many conflicting
> goals, and the solution is far from obvious. If we can solve it, and I am
> unreasonably optimistic that a solution is possible, then we will have obtained
> a language that is easier to read, easier to write, and more resistant to
> error. If we get it wrong, then we will have accomplished something far worse
> than having done nothing.
The elephant in the room is significant whitespace including newlines. I have said this seems something we can't standardize in ECMA-262. I think this for a couple of reasons:
1. Because it requires new lexical and syntactic grammars, and possibly a CoffeeScript-like "rewriter" in between.
2. Changing to significant space and newlines risks changing the meaning of extant JS. Consider CoffeeScript's paren-free actual parameter lists to function calls.
Maybe there's a safe and modular way to "add" significant whitespace and newlines. But we'll need the current mostly-insignificant spec language forever, for non-opt-into-Harmony code, so some variant of 1 remains.
/be
More information about the es-discuss
mailing list