[ruby-talk:5590] Re: local variables (nested, in-block, parameters, etc.)

On Mon, 16 Oct 2000, ts wrote:

>  Perhaps (and certainly :-)) I'm stupid  but why it make ruby more
>  complex ?
> 

I think the problem is not what ruby is missing but rather what it gives
(in analogy with the lack of goto in high level languages).

IMHO the solutions proposed up to now are not completely satisfactory
since they introduce (in some form) a new construct with the standard
semantics but leaves a construct with "unclear" semantics.

I propose to back up to the solution proposed in [ruby-talk:5543], i.e.
treat all the parameters as fresh variables.

The main argument against this, seems to be incompatibility, IMHO this
should not be a real problem, for the following reasons:

- We are not talking about Fortran. Ruby is a relatively new language and,
a dynamic one. New features, library, ecc... are introduced day by day. If
you think that the new treatement of blocks is more appropriate no price
is high enough to hinder the new development.

- The "feature" we are talking about (the previous behaviour of block
parameters) is strange enough to be not extensively used. And so I think
it unlikely occurs in real code. I would like to see an example in which
using this feature one would relly gain something (clearness,
expressivness, ...).

- We can check syntactically if this occurs in old code. Using the ruby
parser code, we could (easily?) write a tool to detect blocks in which
parameters are already bound in the context. I think this could be
also helpful to detect potential bugs due to wrong choices of names for
block parameters.

- We can (easily?) write a code translator from old semantics to new
semantics. If I understood correctly the argument passing in ruby, the
following equivalence shoul hold:

	{|a| p} equivalent to {|x| a = x ; p ; x = a}

where p is a piece of ruby code and x is a fresh variable (not occurring
in p and in the scope in which the block is defined).

- If you think that having also the old semantics is a must, it would be a
better choice (IMHO) introducing a compatibility switch in ruby
interpreter and implementing by default the new semantics.


Sorry, the message is long also this time.

Bye,
					Davide