From: David Alan Black <dblack@...>
Date: 2004-04-15T18:14:11+09:00
Subject: Re: New Local Variable Scope rule

Hi --

"Robert Klemme" <bob.news@gmx.net> writes:

> "David Alan Black" <dblack@wobblini.net> schrieb im Newsbeitrag
> news:m3brluhh6y.fsf@wobblini.net...
> > Hi --
> >
> > ts <decoux@moulon.inra.fr> writes:
> >
> > > >>>>> "D" == David Alan Black <dblack@wobblini.net> writes:
> > >
> > > D>   def call_foo
> > > D>     foo(lambda{|b| c=b})
> > >
> > > D>     puts c                # does c persist if the lambda was
> called?
> > > D>   end
> > >
> > >  What you have written is similar to
> > >
> > >    def call_foo
> > >       a = lambda {|b| c = b}
> > >       foo(a)
> > >       puts c
> > >    end
> > >
> > >  foo(a) don't change anything and if I've well understood : this is at
> > >  compile time that ruby will make the decision (local/block-local)
> 
> Maybe the call should've read "foo &a".
> 
> > OK... but what will the decision be, for 'c'?  Why would it be any
> > different here than for:
> >
> >   def foo
> >     [1].each { c = 0 }
> >     puts c
> >   end
> >
> > In both cases, an assignment is being made to c, visible at compile
> > time, in a particular scope.  So, in your example (and mine), c is
> > created at compile time in the calling scope (call_foo).  Then the
> > lambda is called, and c is actually assigned something.
> 
> Yes, of course.  But there's a difference between
> 
> def foo
>   [1].each { c = 0 }
>   puts c
> end
> 
> and
> 
> def foo(&b)
>   [1].each &b
>   puts c
> end
> foo { c = 0 }
> 
> 'c' comes into existence in the lexically surrounding scope, i.e. foo in
> the first case and the calling context in the second case.  There is no
> magic that would make the second example print something other than 'nil'
> for 'c'.

Right -- see my wording above ("c is created at compile time in the
calling scope", which means foo in your first example and top-level in
your second example, and call_foo in my call_foo example).  I somehow
had the impression Guy was saying that in the call_foo example, no 'c'
would be created in call_foo but I now don't think he was.  (That's
what I meant when I asked why one would be different from the other.)

I still find it odd what happens in that calling scope.  As I
understand it, after calling foo {|b| c = b}, you may or may not have
a variable 'c', depending on the behavior of foo (i.e., whether foo
does or does not call [or yield to] your block).  To me, this
particular kind of dependency between scopes is strange.  

> > Or is there going to be a further distinction between plain lambdas
> > and code blocks passed to iterators?  If so, I really think it's time
> > for a Block class.  (Matz: you wanted more reasons.... :-)
> 
> It would certainly be intersting to hear that.  Up to now I thought
> 'lambda' is merely a syntactical alias for 'proc' but I may be wrong here.

No, you're right.  ('proc' is deprecated in favor of lambda, to avoid
the similarity in name between the non-similar Proc and proc objects.)
But see ruby-core, and probably ruby-talk too in the past; there have
been discussions about the various differences between and among Proc
objects, lambdas, and code blocks.  (I'm not going to tempt fate by
trying to summarize them :-) 


David

-- 
David A. Black
dblack@wobblini.net