"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'.

> 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.

Regards

    robert