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

Reply via email to