From: ara.t.howard@...
Date: 2006-10-11T00:09:57+09:00
Subject: Re: || explanation in ruby... in pseudolanguage

On Tue, 10 Oct 2006, Yukihiro Matsumoto wrote:

> |is there somewhere the new scoping rules are spelled out so we can get a heads
> |up?
>
> Not yet.  I am stuck with the idea named local variable propagation, which
> upgrades variable scope if it is used outside of the scope (and within a
> method), i.e.
>
>  def foo
>    4.times do
>      a = gets
>    end
>    p a  # accessing a upgrades its scope.
>  end
>
> But block parameters and explicitly declared block local variables are not
> subject of this upgrading.


hmmm.  it's kinda like 'scope coercion'.  seems kinda slippery - like

   ' "1" + 41 '

in perl...

plus it gets tricky when one meant to go 'up' a scope, but it went 'down' one
instead:

   i = 42

   # 1000 lines of code

   n.times do |i|
     m.times do |i|
     end
   end

   p i  # goes down or up depending on 'i = 42' line way above...


on the otherhand, if all vars in block are local it's tough to get one out!



would a block local var be declared using something like

   local x

??

or are all block vars simply local by default?



how about an explicit scope upgrade:

   4.times{ export a = gets }

??


another thing which springs to mind is an objectified stack - it could solve
this problem too, working similarly for stack and scope:

stack:

   def foo()
     context = callstack.first  # list of objectified stack objects
     context['a'] = 42          # set local var 'a' in binding of caller
   end

scope:

   def foo()
     4.times do
       context = scope.first   # list of objectified scope objects
       context['a'] = 42       # set local var 'a' in first outer scope
     end
   end

not too mention skinning a bunch of other cats too...

just throwing things out there...  the problem of callstack, scope, and
manipulating them in general (setting vars being one instance) seem related,
but i'm no language designer...


> |is there a reccomended approach that will work in both 1.8 and 1.9 so as
> |to smooth the transition?
>
> Consider block parameters are block local even when you're using 1.8.
> It's a good thing in general, I think.

but, if we also consider block locals as, well, local, what's the prefered
method for getting them 'out'?  for example,

   which = nil
   container.each{|elem| break(which = elem) if predicate[elem]}

are there two 'which' vars here (local and top-level)?  or will 'which' still
successfully be exported?


kind regards.

-a
-- 
my religion is very simple.  my religion is kindness. -- the dalai lama