From: Kevin Mahler <kevin.mahler@...>
Date: 2011-04-15T15:37:17+09:00
Subject: Re: scope of assignments with lambda

Fearless Fool wrote in post #988777:
> What I was surprised about was the scoping of variables in assignment
> statements.  I guess it makes sense.  Assume that p is previously
> undefined, then a reference on the RHS to p like this:
>
>   p = p + 1
>
> will raise an error.  But wrapped inside a lambda, the reference to p is
> deferred, so it all works:
>
>   p = lambda { |n| p.call(n-1) if (n > 0) }
>
> As I said, that's the power of a lexical closure.

"The scoping of variables in assignment" is exactly the same in both
cases.

p = p + 1 does not fail because p is undefined. p is defined. Its
value is nil. The error results from NilClass#+ not existing. This has
nothing to do with "the power of the lexical closure".

Local variables are discovered at compile time. p gets defined at the
beginning of the scope, *before* the line "p = p + 1", and it's
assigned the value of nil. Try

  p = p.to_i + 1

and observe the non-error. Even better, try

  def foo
    puts local_variables #=>bar
    bar = 99
  end

The reference to p inside the lambda is not deferred. At compile-time,
the p inside the lambda is bound to the local variable p, just as the
p on the right-hand side of "p = p + 1" is bound to the local variable
p. There is nothing special going on as a result of the lambda being
present.

-- 
Posted via http://www.ruby-forum.com/.