Forum: Ruby Re: Subclassing Struct.new

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
unknown (Guest)
on 2006-03-01 20:40
(Received via mailing list)
Quoting Yukihiro M. <removed_email_address@domain.invalid>:

> |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
This topic is locked and can not be replied to.