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

[Marcel Laverdet]

So I ended up solving this by basically copy and pasting my expression  
grammar sans the expressions that begin with t_LCURLY. Then an  
expression_statement must be an expression_no_statement t_SEMICOLON,  
where expression_no_statement is the copy and pasted grammar.

ES-262 recommends a similar technique to deal with the ambiguity that  
comes up by using the `in` operator in a `for` loop initializer.
http://www.mozilla.org/js/language/E262-3.pdf
The madness begins on page 167, each rule is repeated once with `in`  
and once without it. What I'm doing is identical except with '{' and  
`function` instead of `in`.

On the plus side, though, with the modifications there are 0 conflicts  
so I don't need %glr-parser anymore. On the down side that introduced  
about 50 redundant rules and added 300 lines to my grammar.

Thanks for the help Hans!

On Nov 14, 2008, at 10:53 AM, Hans Aberg wrote:
> On 14 Nov 2008, at 19:35, Marcel Laverdet wrote:
>
> > 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.
>
> Indeed, for that reason, those two methods do not mix well. There  
> has been talk about admitting GLR actions that are executed  
> immediately, but don't hold your breath.
>
> So you need the parts with the context switches being unambiguous.  
> In addition, lookahead is unpredictable, so typically context  
> switches should be put close to tokens. But one can go quite far  
> with this technique: one has been able to make C++ into a (non-GLR)  
> LALR(1) grammar this way.
>  http://www.parashift.com/c++-faq-lite/compiler-dependencies.html#faq-38.11
>
>  Hans