From: "Guy N. Hurst" <gnhurst@...>
Date: 2001-03-11T04:29:59+09:00
Subject: [ruby-talk:12392] Re: FEATURE REQUEST: 'my' local variables

Kevin Smith wrote:
> 
> matz@zetabits.com wrote:
> >|>  loop {<a, b, c|d, e, f>
> >|>    ...
> >|>  }
> >|
> >|Hmmmm. At a glance, that looks pretty confusing.
> >|I'm so used to | x | that it's jarring having < a
> >|| b > instead. Slight changes to the symbols used
> >|might make it better.
> >
> >So, which symbols are better for them?
> 
> I was afraid you would ask. I'm hoping to avoid
> re-using the <> operators, if possible. And I
> would like to keep | | as surrounding operators,
> rather than now having just one in the middle.

I agree with this sentiment.

However, I think there is another issue which
these new block locals don't solve.

** warning: long discourse ahead **
 
a = 5
d = 9
:
loop{|a,b,c|<d,e,f> .... }
# need new value of d here

See, I'd possibly like to use 'd' without having to
worry whether it already exists, and still have it
available after the block.

To that, I should normally do:
a = 5
d = 9
:
d=0  # but intereferes with 'unknown' d=9
loop{|a,b,c,d|<e,f> .... }
# new 'd' is available, old 'd' is clobbered

Ah, now I still have the 'problem' of dealing
with having to know prior locals.


One possible solution that comes to mind is having the
ability to retroactively access block-local variables.

a = 5
d = 9
:
loop{|a,b,c|<d,e,f> .... d = 3; .... }
# 'd' is still 9
# need some way to access the block-local 'd'
# possibilities:
# 1) d~  (to mean from most recent block)
# 2) Local::d  (also to mean from most recent local block)
# 3) <local-block-name>::d  (from named local block)

#(3) above would imply naming local blocks:
loop{|a,b,c|<d,e,f> .... d=3; .... }~myloop
Local::myloop::d is now available with value of 3
(new problem will be in ensuring we aren't clobbering
the name of some previous block, hehe)

This might also lead to the concept of having accessors
for block-local variables. (read-only)

loop{|a,b,c| <attr :d, e,f> .... d=3; ....} etc.

But I think the way Ruby is implemented, the block-local
variables disappear after the block is over. I think
it uses 'dyna' variables and the stack.

So Ruby would probably have to be modified to somehow
save them inside some kind of scope...maybe even make
them a special kind of instance.
(regular blocks are currently not objects like they are 
in smalltalk)
 
I think G. Decoux could comment here...

The typical considerations of doing this would be performance
and backwards compatibility.

For that, matz might have something to say.

But as I hinted at above, using named blocks will beg
the same 'problem' of having to know previous names so
as to not clobber previous ones.
(Perhaps make ruby keep track and issue error when local
blocks are renamed, or else maybe only allow the most
recent local block to be accessed...)


** warning: additional long discourse ahead **

But even if these block locals and named local blocks
are implemented, it will not necessarily solve the 'problem'
regarding not having to know about variables, because don't
nested blocks, procs, continuations, threads, etc. have the
ability to introduce local variables you may not know 
about, with or without the use of eval()?

In that case, you then would also have to be protected
from all future variables that might clobber your block
local ones from within that same block, because they
may not be using block-local vars themselves.

This past and future scoping 'problem' seems too complex
and will not be easy to fix. Fixing has less to
do with changing source code and more to do with
interface design - i.e. assuming anything we decide
could be implemented easily, it will still be very
hard to decide what should be done.

Maybe this is where some kind of "Scope by Contract"
can be used, analagous to the "Design by Contract"
concept. It would let you ensure that your local vars 
are not clobbering other unknown ones, and that other
unknown ones don't clobber yours. But I do not know
how that should work, either.

Maybe it isn't a Ruby-related 'problem' at all.
Even in the business world, whenever you try claim something 
as uniquely yours, you have to do a trademark/patent search ;-).

For now, I think the answer is to try to know about all
the past and nested local vars, and/or implement your
own system for ensuring nothing overlaps.


Guy N. Hurst


-- 
HurstLinks Web Development    http://www.hurstlinks.com/
Norfolk, VA  23510            (757)623-9688 FAX 623-0433
PHP/MySQL - Ruby/Perl - HTML/Javascript