Forwards-compatible syntax proposal

Waldemar Horwat waldemar at google.com
Wed Jul 9 12:43:09 PDT 2008


I've had a request to repeat the example I showed at the meeting, so here's one:

{
  if (false) {
    // Say we're introducing a new cast syntax '(<expr>) <expr>'
    var y = (int)/fo+/.exec("abcfoo");
  }
  push_the_button = false;
  {
    z = y/x;
  }
}

In ECMAScript parsing and lexing are interleaved.  There is no way to tell without correctly parsing a piece of code whether / starts a regexp or is a division.  In the above example the regexp was meant to be /fo+/, but the syntax error recovery code will instead think that /.exec...y/x is an extended (multiline) regexp, missing the crucial closing brace of the block and the push_the_button = false statement.  Many other syntax errors can lead to this kind of lexer misalignment, hence it is impossible to isolate a syntax error to the first inner block above (or any other similar syntactic construct), despite the fact that it never executes due to the if (false).  You can make guesses based on indentation and such but guesses don't belong in a standard.

    Waldemar


Waldemar Horwat wrote:
> This wouldn't work.  Without syntactically distinguishing a / that is a 
> division from a / that starts a regexp, there is no way to find the end 
> of the block.  To make this distinction you need to be able to parse the 
> contents of the block without errors.
> 
> To complicate matters further, various language extension proposals, 
> ranging from ES3.1 to various ES4 extensions, muck with the regexp syntax.



More information about the Es4-discuss mailing list