From: davekam@... (Dave)
Date: 2003-04-25T02:51:41+09:00
Subject: Re: two oddities in ruby 1.8.0p2

Brian Candler <B.Candler@pobox.com> wrote in message news:<20030424075455.GB32891@uk.tiscali.com>...

> It's nothing to do with blocks. It's because of the method/local variable
> ambiguity.
> 
> The decision "is x a local variable or is it a method?" is made
> *statically*, at compile time, as the code is being read in and turned into
> a syntax tree. The rule is that if any statement of the form 'x = ...' has
> been seen earlier, then a standalone 'x' is treated as a local variable, not
> a method call.

Oh, right... yeah, if I knew it had anything to do with that, I could
have found the discussions.

I'm still a bit confused, though. I've read messages from matz here
saying that he is against declarations that are for the sole purpose
of helping the compiler figure out what's going on. And yet that is
effectively what must be done in this case -- some declaration like x
= nil. It seems that the compiler has no lookahead -- when it sees
"puts x if defined? x" it must decide then and there, based on what it
has seen until that point, if x is a variable or method. It doesn't
matter that even the very next line uses x as a variable.

Is there a particular reason that such decisions can't be postponed
until the rest of the current scope region has been looked at? The
semantics would make a lot more sense then, I think, even though it
might not take care of everything (like eval "puts x" for example,
before x is defined).

Anyway, I don't quit understand the rationale for having it behave as
it does now. I'll keep reading old threads. Thanks for the
explanation.

Dave