Dave Thomas <Dave / thomases.com> wrote:
> matz / zetabits.com (Yukihiro Matsumoto) writes:
> 
> > For example:
> > 
> >   lambda{<a,b,c|d,e,f> ...}
> >   # a,b,c as parameters.
> >   # d, e, f for local variables valid during the block.
> 
> Seems like the best of both worlds (except you'd probably need a
> character other than '|' as the separator, for the case where you want 
> non-local parameters but local variables.
> 
>    lambda { <a,b % c, d> ... }   local params and local vars
> 
>    lambda { |a,b % c, d| ... }   current params and local vars

I really, really dislike this discussion (please hear me out).  This syntax 
itself isn't too bad, probably useful enough to some people, but I honestly 
believe the problem is exactly as the first poster stated and nothing more.  

If I have the code:

	x = 0	# must initialize x anyway for it to be bound this way
	(1..3).each {|x| puts x}
	puts "Last was ", x

How is it nearly as clean as:

	x = 0	# must initialize x for it to be accessible by the block
	(1..3).each {|y| x = y; puts x}
	puts "Last was ", x

?  The former is just not useful at all.  It violates POLA because it 
introduces a scoping rule that makes things harder on the user by requiring 
them to remember every local variable already used if they don't want to 
accidentally mess something up.

The user already has to explicitly initialize a variable that he wants the 
block to modify.  You won't make it easier on people who know what they're 
doing because they already know the scoping rules; you won't make it easier 
for newbies because they would never expect  the current behavior.

The behavior as it is now is harmful because it is not consistent with 
methods (and a lambda is just that, an anonymous method...).  The form of
lambda {<a, b | e, f>} doesn't make things easier to understand (the user 
still has to look specifically for if whether e and f are already defined to 
determine if they will be local or not).

Oh well.  It doesn't seem like there is a compelling reason to not make 
variables automatically localized to the block.  What's useful would be a 
local variable but non-parameter syntax, a way to be sure that if you see 
only this little bit of code that you know it won't reach outside of its 
bounds.  But inheriting variables in the _arguments_ to a block is just 
inconsistent, and it should be no question of whether or not there should be 
a syntax to allow both...

--
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 green / FreeBSD.org                    `------------------------------'