Quoting Yukihiro M. [email protected]:
|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))
versus:
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
grammar.
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…
-mental