From: Davide Marchignoli Date: 2000-10-17T00:59:46+09:00 Subject: [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