Re: value by reference

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?