Interpretation as a local variable overrides method name?

Question

As in this question, when a local variable not defined is used within its own assignment, it is evaluated to nil.

x = x # => nil 

But when the name of a local variable conflicts with an existing method name, it is more tricky. Why does the last example below return nil?

{}.instance_eval{a = keys} # => []
{}.instance_eval{keys = self.keys} # => []
{}.instance_eval{keys = keys} # => nil

Answer 1

In Ruby, because methods can be called without an explicit receiver and without parentheses, there is a syntactic ambiguity between a local variable reference and a receiverless argumentless method call:

foo

could either mean "call method foo on self with no arguments" or "dereference local variable foo".

If there exists a local variable foo in scope, this is always interpreted as a local variable dereference, never as a method call.

So, what does it mean for a local variable to "be in scope"? This is determined syntactically at parse time, not semantically at runtime. This is very important! Local variables are defined at parse time: if an assignment to a local variable is seen by the parser, the local variable is in scope from that point on. It is, however, only initialized at runtime, there is no compile time evaluation of code going on:

if false
  foo = 42 # from this point on, the local variable foo is in scope
end

foo # evaluates to nil, since it is declared but not initialized

Why does it make sense for local variables to "shadow" methods and not the way around? Well, if methods did shadow local variables, there would no longer be a way to dereference those local variables. However, if local variables shadow methods, then there is still a way to call those methods: remember, the ambiguity only exists for receiverless argumentless methods calls, if you add an explicit receiver or an explicit argument list, you can still call the method:

def bar; 'Hello from method' end; public :bar

bar # => 'Hello from method'

bar = 'You will never see this' if false

bar # => nil

bar = 'Hello from local variable'

bar      # => 'Hello from local variable'
bar()    # => 'Hello from method'
self.bar # => 'Hello from method'

Answer 2

Short answer is, because Matz defined it so. This behavior is one of the very few things I don't like about Ruby. It even gets better:

a = b if a
=> nil
a
=> nil

Variable a gets initialized to nil even though in theory a = b statement should under no circumstances be executed.