May 24-26 rough meeting notes
brendan at mozilla.com
Fri May 27 19:36:38 PDT 2011
On May 27, 2011, at 6:42 PM, Brendan Eich wrote:
> On May 27, 2011, at 6:20 PM, Waldemar Horwat <waldemar at 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.
More information about the es-discuss