On 17 Nov 2008, at 20:48, Marcel Laverdet wrote:
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.
Good, if you have solved your problem; one can often handle
ambiguities by other techniques than GLR. Getting it to work is the
number one priority of course, but it is important to keep it
maintainable, and structure is important for that. So you might still
check if some of the other techniques help with that.
Thanks for the help Hans!
You are welcome.
Hans
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison