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
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison