Quoting Yukihiro Matsumoto <[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 _______________________________________________ Rubygrammar-grammarians mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygrammar-grammarians
