From: Daniel DeLorme <dan-ml@...42.com>
Date: 2008-10-02T14:16:57+09:00
Subject: Re: ruby1.9 block scope

Mike Gold wrote:
> Because you've hardly ever used Class.new, and therefore are probably 
> not familiar with run-time generated classes which present a given 
> binding as different views to external onlookers, then you won't 
> appreciate what I have to say.  To you everything is blub, and you 
> wonder why non-blub things are necessary.  It's a paradox, that you need 
> to understand before you can understand.  See 
> http://www.paulgraham.com/avg.html
> 
> The strategy I've described comes from Lisp.  And it's awesome.

Just because I've hardly ever *had* to use Class.new doesn't mean that I 
don't understand how it works or that I'm some kind of idiot. It's true 
that I don't appreciate what you have to say. And I imagine 99.9% of 
ruby coders won't either. The problem you describe is, by your own 
admission, rooted in using ruby as an alternative lisp. It's great that 
ruby is so flexible that you can do that, but ultimately ruby is ruby, 
not lisp. I wouldn't hold back the language just so that it can stay 
more like another language.

> In fact I think my example does suffice.  You just need to imagine it 
> being using on a slightly larger scale.  As I said previously in this 
> thread, "it would be convoluted to create all new scopes each with 
> instance variables pointing back to the places I just came from.  The 
> code would be Java-like: reams of scaffolding which serve no end except 
> to compensate for a missing language feature."  Do you have a response 
> to that?  Please don't repeat your argument yet again; instead, try to 
> understand what I've said.

I apologize for repeating myself. In my defense, your argument is 
gibberish to me so there's not much I can reply to. If you're talking 
about added complexity in the interpreter, I fail to see how that should 
affect the language's design. And if you're talking about added 
complexity in the ruby code, I fail to see how the proposal has anything 
to do with instance variables or would require additional "scaffolding". 
At most you'd need to avoid re-using variable names in a given scope, 
and that good programming practice anyway.

> Yes, I backtracked just now, before I read your last sentence above.  I 
> checked to be sure that 'changed' means a local variable.   I have to do 
> this with every variable in arbitrarily long scopes.  You are thinking 
> in terms of small examples, but I am thinking about large ones.
> It is O(n^2) complex because it requires a backtrack for each case.  I 
> like to be certain what code does.  I will always backtrack in order to 
> be certain.

Ok, I now see that it is indeed O(n^2) complex. But you *already* have 
to do that for large scopes; you have to consider every variable that 
previously appeared in the scope, and that's O(n^2). The new rule would 
make it 2*O(n^2) [which, in math speak, is still O(n^2)]. But this is 
only a problem if n is very large; if you really have a scope that long 
then I dare say that you already have a problem and some refactoring is 
in order. Whatever happened to "no more than 10-20 lines per method" ?

--
Daniel