On May 27, 2011, at 6:42 PM, Brendan Eich wrote: > On May 27, 2011, at 6:20 PM, Waldemar Horwat <walde...@google.com> wrote: > >>> This produces expressions such as 42 = foo(), which must be handled by >>> semantic specification. Why can't we have a more precise grammar? >> >> This is an entirely different issue. The LeftHandSideExpression is still >> evaluated as an expression; you just don't call GetValue on it. We chose to >> prohibit 42 = foo(); we could equally well have chosen to prohibit foo = >> 42(), but neither situation has much to do with the grammar. > > That dodges the big "cover grammar" vs. Precise Grammar issue before us. It > assumes the conclusion tha semantics such as Reference internal types are the > way to go, because LR(1) can't hack it.
Again, real browser JS engines use top-down parsing and no Reference type, instead specializing the AST for LeftHandSideExpressions to be precise, with early errors per ES5 (and even in ES3 era) for nonsense-LHS-expressions. This is not an argument to remove Reference types from the spec. Maybe we should if we get a better parsing algorithm and grammar. There is a web of trade-offs. >> I realize that C++ and Perl put up with ambiguity, and it seriously bites >> them. Quick, what's the difference between the following in C++? >> >> int x(int()); >> int x(-int()); > > Yet C++ is wildly successful inside Google and outside. Trade-offs... I hasten to add that I'm not endorsing the undecideable crazyland of C++ syntax. Simply pointing to trade-offs taken differently in other languages that are surely successful in spite of lack of precise-enough LR(1) (cover) grammars. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
