Glenn Parker wrote:
See my earlier posting about the lambda { } and Variable[:name] ways of doing this.
Sorry, but I can't believe anybody would actually want to use the lambda styles as proposed. They are ugly and obscure.
They are wordy only when you want to increment multiple variables from the outside. That does not hold true for simpler cases:
def inc() yield(1) end
inc { |x| var += x }
Or yet simpler:
def inc() yield end
inc { var += 1 }
I've not yet seen any sample code where the existing ways would not be simple enough. Note that it's possible to write inc(Variable[:x]) when using variable.rb. The implementation is reasonably straight-forward so I don't see why something like this has to be included in core Ruby. Especially not if it seems to be so rarely used in real world code. (Unless said user is using it as a replacement for something that is usually done in a simpler way in Ruby.)
Ruby itself just treats variables as names for Objects. You can't really refer to a variable itself, you can only refer to the Object it is a name for. That's a surprisingly simple and non-confusing model.
Judging by the frequency that this issue is discussed, it's more confusing than you suggest. A typical programmers expects call-by-reference to work one way, and Ruby works differently.
Which might be entirely related to Ruby not being like every other language out there. (And not every other language out there is like every other language out there either.) Personally, I think Ruby's semantics when it comes to variables and argument passing are way less confusing than the ones in Perl and PHP.
If I'm not completely wrong Python, LISP, Smalltalk and JavaScript work exactly in the same way that Ruby does.
Extra confusion results because this difference is masked by using self-updating methods
I've not yet seen a language that tries as hard as Ruby to distinguish between in-place and result-style methods. Other languages usually just do nothing about the issue at all. In that case you have to read the documentation to know what is happening. (Frequently operations are in-place unless the Object is a Value object.)
but it always fails for immediate objects
Of course. How would you change the value of an immutable Object?
and it eventually fails in a surprising way for non-immediate objects. I call it surprising because a typical programmer does not expect the assignment operator to destroy call-by-reference, but that is exactly what happens.
def inc1(a, i); a += i; end
def inc2(a, i); a = a + i; end
To the naive Ruby programmer, inc1 and inc2 seem to be equivalent, but Ruby gurus just shake their heads and sigh while they explain, yet again, that there is a difference. Why is this considered a good thing? 
I fear that most people confuse themselves by assuming that Ruby works like other languages they know. That leads to a confusingly over-complicated model. Just forget everything you know and get your knowledge from the Pickaxe. Ruby's model is really quite simple, but people are constantly making up broken metaphors for themselves which is not worth the effort at all...
I think the above code is an example of this. I don't see why the two should be different and unless matz went insane over night they aren't.
You might say that the typical programmer has grown accustomed to a confusing model, and Ruby is better off without that model. But, that is nigh on saying that Ruby is better off without the typical programmer. And that would be a shame, since Ruby has much to offer the hordes of Perl and Python programmers looking for something better.
There's nothing wrong with being used to model's of other languages, but it's a bad idea to mix them up when they don't match.
There's not one true model for everyone, but Ruby's certainly makes sense.
Ruby does *not* support call-by-reference, in the traditional sense of the term. Instead, it is strictly call-by-value, and formal paremeters are copies of references from the calling scope. If Ruby had real call-by-reference, then it would be trivial to define a procedure that updates a variable from its parent's scope, and inc1 and inc2 above would be equivalent.
I'll still want to explain this differently, to keep confusing at a minimum:
Ruby does not pass references to variables, it passes references to Objects.
(Variables are no shoe boxes in Ruby, they are just names for things.)
Tcl is similar to Ruby, regarding both the style of variable passing and the resulting confusion among its new adopters, but Tcl documentation has always stressed the details of this issue, and the Tcl core has the "uplevel" and "upvar" builtins. I'm not a huge fan of Tcl, but I do think the Tcl folks handled this issue in the best way possible.
I'm not experienced at Tcl. What do those built ins do?
