I did it again. I should check my mail preferences for replying.
--
Hey,
On Feb 21, 2008 12:00 AM, <[EMAIL PROTECTED]> wrote:
> I see. It seems to me that you may need a way to distinguish
> syntactically between a plain object and an object returned by a call to a
> function (sorry, I won't ca
Well, I solved my problem. Quickly enough, I know, but it was a week or so
before this of thinking. I'll explain it if anyone's interested.
In Ruby, since an identifier could be a local variable or method at runtime,
and we don't know which, we can't differentiate the two in the parser.
Hence, fun
I didn't send this to list. Trying again, sorry!
On Feb 20, 2008 10:19 PM, <[EMAIL PROTECTED]> wrote:
> > 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.me
I'll add a bit of information. After using parser tracing, I've found in
fact this is happening:
a(b).c is being parsed as `a(b.c)', however the reasoning is different;
after reading `a(b)' it reduces just `(b)' by the rule for parenthesised
expressions, '(' *expr* ')'. The rest falls into place.
Hi all,
I've been trying to nut out a problem for a week or so in a bison parser
I've been writing, and I'm failing. Please excuse me if this isn't the
correct place to ask - I haven't convened with anyone about bison parsers
before.
I'm writing a parser for Ruby (http://www.ruby-lang.org/). So f