May 24-26 rough meeting notes

Brendan Eich brendan at mozilla.com
Tue May 31 13:34:49 PDT 2011


On May 31, 2011, at 1:21 PM, Waldemar Horwat wrote:

> On 05/27/11 19:36, Brendan Eich wrote:
>> 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.
> 
> Top-down LL parsers are subsumed by LR parsers.  The hierarchy is:
> 
> LL(0) < LL(1) < LR(1). LR(0) < SLR(1) < LALR(1) < LR(1).

Yes, I know -- but that is not in practice so helpful to implementors, since they have to (at least) tediously refactor to remove left recursion.. The reason to use LR(1) in the spec is not to help implementors, as far as I can tell.

The reason to use LR(1) that you have cited is to have a validated-unambiguous grammar using a well-known formalism. It's a good reason, but it applies to other approaches.

Is there anything particularly compelling about LR(1) vs. say PEG (which is unambiguous by construction) -- linear time, memory proportional to PDA depth, or other? I have my own thoughts but I'd be interested in yours.

/be


More information about the es-discuss mailing list