From: Robert Klemme Date: 2007-09-11T06:10:07+09:00 Subject: Re: Bug in lambda? On 10.09.2007 19:05, Wilson Bilkovich wrote: > On 9/10/07, dblack@wobblini.net wrote: >> Hi -- >> >> On Mon, 10 Sep 2007, Robert Klemme wrote: >> >>> 2007/9/9, 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 What output would you prefer? I don't see how this can print "7" if that's what you were up to. In fact, I would be scared to see that. :-) Actually the original issue was different IIRC, because the block was defined in a scope which had the block parameter as a local variable which is not the case in your example. Kind regards robert