Guy Decoux wrote:

# >>>>> "C" == Conrad Schneiker/Austin/Contr/IBM <schneik / us.ibm.com> 
writes:
# 
# C> (1..10).each{|i| (x = i; break) if (i == 4)}
# 
#  It depend how you interpret |i|
# 
#  Apparently many people (like me) see |i| as arguments, when ruby seems 
see
#  only a multi-assignement.
# 
#  ruby is consistent in the sense that it give the same result for this
#  example :
# 
#   a = x = 0
#   [[1, 2]].each do |a, b|
#       x, y = a, b
#   end
# 
#  a and x are local variables
#  b and y are dynamic variables.

Well, your argument viewpoint and parallel assignment viewpoint are 
certainly good points.

However, I am still not too happy with arguments being coupled to 2 
different sources, as it were, which somehow seems contrary to the really 
nice "wrapping" nature of iterators, as it were. It still seems a little 
too Perl-ish in terms of context-dependence. Plus the initial references 
to a and x might not always be so near to the iterator, as they were in 
your example. 

Speaking of arguments, maybe |(a), b| could be used (with reference to 
your example) to mean that a's scope transcends the iterator, while b is 
strictly iterator-local. I think this would be cleanest way for the most 
common cases (although if backward compatibility were the top concern, the 
convention would be the other way around).

==============================================================

Incidentally, on an unrelated topic, I discovered that if I put:

  p(a, b)
  p(x, y)

after your code and run it, I get

  block2.rb:5: undefined local variable or method `b' for 
#<Object:0x20063370> (NameError)

Is there a good reason why this should really die with a NameError rather 
than just telling you that the argument is undefined and going on?

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)