help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: When %dprec and %merge aren't enough...


From: Marcel Laverdet
Subject: Re: When %dprec and %merge aren't enough...
Date: Fri, 14 Nov 2008 10:35:19 -0800


This is a pretty good idea, but I'm not sure if it's possible. For instance in the case of an if statement I modified my grammar as such:

if_statement:
t_IF t_LPAREN expression t_RPAREN {yyexpect_statement;} statement t_ELSE statement
<...>
| t_IF t_LPAREN expression t_RPAREN {yyexpect_statement;} statement %prec p_IF
<...>
;

Where yyexpect_statement is a macro I defined to set a global flag and then the lexer checks and returns an appropriate t_LCURLY for statements. The problem I'm seeing here is that the glr parser defers my mid-action rule so the lexer can't adjust in time.


On Nov 11, 2008, at 11:08 AM, Hans Aberg wrote:
On 11 Nov 2008, at 08:10, Marcel Laverdet wrote:

It's unclear here whether the child of the if statement should be an empty Block or an empty ObjectLiteral. The ECMAScript spec addresses this simply: "Note that an ExpressionStatement cannot start with an opening curly brace because that might make it ambiguous with a Block."

You might try defining two pairs of braces, one for the blocks, an one for the statements. This should disambiguate the grammar. Then set a context switch that tells the lexer which type to return; the switch is changed from the parser.

 Hans





reply via email to

[Prev in Thread] Current Thread [Next in Thread]