Function Syntax

[Brendan Eich]

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