From: Wilson Bilkovich <wilsonb@...>
Date: 2007-09-11T02:05:09+09:00
Subject: Re: Bug in lambda?

On 9/10/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
> Hi --
>
> On Mon, 10 Sep 2007, Robert Klemme wrote:
>
> > 2007/9/9, dblack@wobblini.net <dblack@wobblini.net>:
> >> Definitely not a bug. Block parameters use assignment semantics, with
> >> regard to the scope in which the block appears. In your example,
> >> you're assigning 1 to a. If you create a local variable inside the
> >> block, however, it only exists for the duration of the block.
> >>
> >> As far as remember, Guy Decoux and I are the only two people who think
> >> that this makes perfect sense, once you learn it, and should not be
> >> changed :-)
> >
> > Now I'm curious: how often do you have use for this feature?  I mean,
> > if block parameters were locally scoped you just had to punch in one
> > more assignment to get the same effect like the current version:
> >
> > def foo
> >  x=1
> >  lambda {|a| x=a}
> > end
> >
> > Do I miss something?
>
> I don't think so, but part of the problem for me is that there's no
> problem -- in other words, I learned that it works with assignment
> syntax, and probably haven't made all that much use of it but never
> thought there was any reason for it *not* to work that way. I suppose
> it's possible to clobber variables, but then it's possible to do that
> without blocks, too, if you're not careful about variable names.
>
>

I think that the original poster was worried that this script would
print "7". If that's not the case, forgive me. :)

def do_it x, f
  f.call 7
  p x
end

f = lambda {|x| x}
do_it 1, f

The existing behavior seems much scarier in IRB than in 'real' code.