Forum: Ruby Re: Subclassing

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2006-03-01 19:40
(Received via mailing list)
Quoting Yukihiro Matsumoto <>:

> |Will the Ruby2.0 grammar no longer have variable/method
> ambiguities?
> I'm not sure what you meant by "ambiguities".  The identifiers
> not assigned in the scope will be treated as method calls, as
> well as in current behavior.

When speaking of grammar, "ambiguity" refers to situations where the
same text can parse to more than one tree -- for example:

 foo[1]  # (call (lvar foo) [] (array 1))
 foo [1] # (call (lvar foo) [] (array 1))


 foo[1]  # (call (fcall foo (array)) [] (array 1))
 foo [1] # (fcall foo (array (array 1)))

There may be disambiguating factors (e.g. whether 'foo' is known a
priori to be an lvar or a method), but those are external to the

Rather than making the grammar itself ambiguous, it would be better
to introduce a new 'lvar-or-fcall' production parse the above
expressions unconditionally as:

 foo[1]  # (call (lvar-or-fcall foo) [] (array 1))
 foo [1] # (fcall foo (array (array 1)))

This way, it would be possible to write an unambiguous context-free
grammar for Ruby (heredocs and so forth aside).

Also, it would help users confused about whether "foo [1]" parses as
a method call or a variable access, since "foo 1" always parses as a
method call.

You'd still be free to backpatch the lvar-or-fcall node to an lvar
or fcall if you wanted to do so, but it wouldn't complicate the
grammar any longer.

Please don't make Ruby even harder to parse...

This topic is locked and can not be replied to.