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