[ruby-talk:14649] to be local or not to be local [was Re: Arggg Bitten by the block var scope feature!!!]

This issue has been a couple of times thru the cycle on this list.

I've enormous respect for Matz's insight and his judicious design choices
he has made in harmoniously blending features into Ruby.  But the need for a
difference between 'procs' and 'methods' has intrigued me.  I'm not able to
fully understand nor appreciate why these two have to be treated differently
(e.g. the way in which they accept parameters --- different behavior of |a|
in procs vs methods, method params being local while proc params are not
etc).

Matz has expressed his interest in introducing the <...> notation.

But I still am not sure why folks think its a good idea for |x,y,z| to be
potentially non-local.

In 

        method(a1,a2) {|x,y,z| ...}

The -only- reason I can see for not having x,y,z as local variables is the
(slight?) efficiency boost one gets --- every time you invoke the block you
don't have to allocate the new vars if they already exist.  Perhaps Matz has
run some tests on this but I'm not sure if such a slight boost is worth the
potential problem.  Also, making a design decision in this manner
(efficiency over avoiding surprise) seems not to be in the spirit of the
overall design of Ruby.

Suppose |x,y,z| were true local vars (as in method params) you could still
assign non-locally if you really wanted to by:

     n=10
     ...
     foo (10) {|x| n=x; ...}

Few view points I have been put forth in favor of |x,y,z| being non-local

1. "it is bad practice to shadow variables."

    I agree.  

    But my view is that the problem is not so much about
    "deliberate shadowing"  as it is about  "inadvertent capture".
    During refactoring, local code modifications and even during first time
    writing it is possible for accidental "inadvertent captures" to take
    place.   
    
    Not just with blocks but with procs too:

      x=10
      ...
      poly = proc {|x| 10*x**2 + 5*x -2}

    Dangerous inadvertent capture!  Should not the language protect us
    against this?

2.  "In C we  have to be careful about the following situation:
         i=20
         ...
         for (i=0; i<100; ++i) {
             ...
         }
   Block params should be handled with the same care."

   In C we had to live with that.  But to avoid the very same problems we
   are currently talking about C++ (and Java) introduced loop local
   variables:

         for (int i=0; i<100; ++i) {
            ...
          }

   Last I looked even the C 9X draft standard has loop local variables.

3.  "Such captures don't happen that often.  In any event the programmer
    should be more careful."

    This view point is some what in the line of preferring programmer
    managed memory as opposed to automatic memory management.  when coding
    in C/C++ no matter how careful I am, now matter what tool I use (purify
    etc) I will still have the nagging doubt as to whether there is a memory
    leak some where.

    The Lisp folks figured this out some 40 years ago in the early 60s.
    Some 30 years later other languages slowly started catching on to the
    benefits of automatic heap management.  With garbage collection you've
    practically got an iron clad guarantee that there will be no dangling
    reference errors.

    Same here.  Making proc/block params local makes an entire class or
    potential problems a non-issue.

Maybe I'm wrong (as is not that un-common) and I'm not seeing something.
But I can't figure out anything in favor of having |x,y,z| be potentially
non-local but for efficiency.

Not second guessing nor trying to start a vociferous debate but am just
interested in views from the "its ok/desirable for |x,y,z| to be non-local"
camp as to why the status quo is fine.


Regards,
Raja