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

Hi,

In message "[ruby-talk:5590] Re: local variables (nested, in-block, parameters, etc.)"
    on 00/10/17, Davide Marchignoli <[e-mail]> writes:

|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.

Well, Ruby is far younger than FORTRAN, and you may have found it
recently.  But it have been there for at least 5 years (for me, 7
years).  There are probably tens of thousands of Ruby programs
already.  I don't deny introducing incompatibility.  In fact, I did
many times.  But we should be careful to do so.

|- 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, ...).

When you use blocks as lambda/closure, yes.  But not that strange when
you use blocks for iteration.  That's the problem.

|- 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.

Agreed, once consensus be made up that block parameter should be block
local, even for iteration.  From this point, using <> for block
parameter used for closure arguments is bit more acceptable for me.

|- 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.

No, global switch is a bad idea.  It makes serious (even unacceptable)
gap between new and old code.  You can't mix them.  Let us look for
other workaround.

							matz.