On 20 Feb 2008, at 09:00, Arlen Cuss wrote:
I'm writing a parser for Ruby (http://www.ruby-lang.org/). So far,
it can
parse a sizeable subset of the language. The problem I'm
encountering is as
follows:
`obj.method' is a method call on `obj'. This is parsed correctly.
`obj.method(args)' is a method call with arguments given. Also fine.
`obj.method(args).another_method' is a method call to `obj' with some
arguments, then a method call to the return value of that method.
This is
parsed incorrectly.
A shift/reduce conflict occurs where `obj.method(args)' is seen by my
parser. Instead of reducing when it sees the upcoming `.', it
shifts, and it
ends up with the whole `obj.method(args).another_method' on the
stack. Then
it reduces, and we get `(args).another_method' and hence
`args.another_method'. It's recognised by the parser as something like
`obj.method(args.another_method)' instead.
I'm trying to work out how to convince bison to reduce at this
point, by
manipulating the precedence of ')', '.', etc., but so far to no
avail. Any
ideas? I'll be happy to post the code on request.
The general method to set token precedences for resolving S/R
conflicts is to look in the .output file for the conflicting states,
and in them, at the tokens immediately before and after the parsing
dot "." in those rules. The set token precedences on those.
In your case, it seems that the method "." should be parse the the
left, as in "+" say, and not to the right as in "=". So try use a %
left ".".
Also, there is a Yaccable C++ grammar that might have similar
constructs:
http://www.parashift.com/c++-faq-lite/compiler-
dependencies.html#faq-38.11
Hans Aberg
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison