Hacker News new | comments | show | ask | jobs | submit login


I'm uninterested in any specifics, actually; I'm more interested in how much of the syntax landscape is cut off for future extension, particularly at the expression level.

It's one thing to insert semicolons in this case:

  <ident> <op> <ident> <op> <ident>
and another to do so in this kind of case:

  <ident> <op> <ident>
  <op> <ident>
The former is unlikely to be problematic for future extension, but the latter more so. The general pattern in Algol-derived languages is for all statements (except for expressions, including assignments and procedure calls) to begin with a keyword. This substantially reduces ambiguity - semicolons are mostly redundant in this situation - and it seems to me to be a fine place in JS to automatically insert them.

Another distinctive feature of Algol-derived languages is that two adjacent expressions are generally not meaningful; for example, <ident> <ident> is not usually a valid expression sequence in Pascal, C, etc. (and in the presence of typedefs, it is actually a concrete problem when trying to parse C declarations, often requiring communication between lexer and parser to turn typedef identifiers into keywords for the purpose of parsing[1]). This in turn creates freedom for creating new keywords unambiguously, by including whitespace in the "keyword" (actually two words). But JS foregoes some of this, because <ident> \n <ident> will have a semicolon inserted on the line break. It's not too bad though, because new two-word "keywords" are not usually broken over two lines; but long expressions almost always extend over multiple lines at some point.

Do you see what I'm getting at here?

[1] http://calculist.blogspot.co.uk/2009/02/c-typedef-parsing-pr... has what seems to be a reasonable overview of this problem.


No, we should not. We should look at principles, because principles are what guide us on judging specifics.

If you don't understand why I take this approach, you will never understand my position.

The 'latest revision of the future specification' you link to is, I think, the set of things the TC39 group has considered and agreed on. The list of things they are currently considering is in the strawman namespace[1] on that wiki. In particular, the "strawman:concurrency" page[2] currently says:

The infix “!” operator: An eventual analog of “.“, for making eventual requests look more like immediate requests.

[1]: http://wiki.ecmascript.org/doku.php?id=strawman:strawman [2]: http://wiki.ecmascript.org/doku.php?id=strawman:concurrency


> But... surely that code is far more "insanely stupid[-looking]" than the first...?

I don't think anyone is arguing that x\n!p is a good way to write code. Crockford is pointing out that ASI will not occur when ! is an infix operator.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact