From: Robert Klemme <shortcutter@...>
Date: 2007-10-02T07:05:15+09:00
Subject: Re: Reference vs. Reference

On 01.10.2007 22:07, Robert Dober wrote:
> On 10/1/07, Robert Klemme <shortcutter@googlemail.com> wrote:
>> I feel there is a subtle point that needs clarification.
>> Unfortunately the term "reference" does not have an unambiguous
>> meaning in our field.  I know at least these meanings
>>
>> 1. R. is a general term for any programming language construct that
>> allows to reference a value.  This does not sound very involved but
>> it's actually as simple (or: as general) as that. :-)  Unfortunately
>> this includes things like C pointers, Pascal pointers, C++ references,
>> Perl references, Ruby references (Matz, is this the proper term?) etc.
>>
>> 2. C++ R. type is a special beast which has some additional properties
>> compared to 1. This does not only allow to reference a value but in
>> fact you can say that it references a reference[1]. Or you can say
>> that a C++ reference is an alias for a variable.  Hence it allows to
>> manipulate a variable in a calling scope.
>>
>> See also http://en.wikipedia.org/wiki/Reference#Computer_science
>>
>> Ruby's evaluation strategy is actually "call by reference"
> Sorry Robert but I challange that statement,

It's a free country... :-)

> "call by value" by all means
> I also think that I am not the only one to do so.

You are not insinuating that the truth value of your statement somehow 
depends on the higher number of supporters, do you? :-)

> If it were call by reference we could change parameters of immediate
> values, which we can not:
> a = 42
> def change b
>    b = 22
> end
> change a
> p a # --> 42

Well, I believe the error is in reading "reference" in "call by 
reference" as "C++ reference" (see the initial section of my posting). 
In C++ land "reference" has a special meaning that is not identical with 
the general term "reference", which is used in the equally general term 
"call by reference".

Counter challenge: If Ruby was using "call by value" this bit would 
print "" and not "X", because t() would see a /copy of the string/:

$ ruby -e 'def t(x)x<<"X"end;s="";t s;p s'
"X"

>> although
>> the description at
>> http://en.wikipedia.org/wiki/Call_by_reference#Call_by_reference does
>> not cover Ruby properly - unless you interpret "temporary object" as
>> "copy of a reference" because this is how it works.
> Maybe call by copy is the exact term; what you think?

I have never heard this term before; I would guess it's not a standard 
CS term.  One could argue that Ruby uses something like "call by copy of 
reference" because that's basically what happens.  But I haven't seen 
this term either; I don't think it is standard.  So I'd say it's "call 
by reference" because that describes best what happens, especially that 
callers see manipulations of objects.  And the fact that Ruby does not 
have the aliasing effects that C++ references exhibit does not 
disqualify the term "call by reference" for Ruby.

Behavior wise it's the same as passing a pointer to a C function.  You 
can change the pointer in the function without affecting the pointer in 
the caller.  Yet both refer on function invocation to the same value.

>> Note: I do not cover special cases like Fixnums here because from the
>> Ruby programmer's perspective there is no difference in behavior -
>> just in speed and memory.
> Why would Fixnums (e.g. intermediate values) be a special case for
> call semantics?

Because technically (i.e. under the hoods) the reference *is* the value. 
  But from a language behavior point of view (i.e. ignoring the 
implementation) there is no observable difference.  I always find it 
easier to grasp when this special case is not pointed out initially. 
It's a mere implementation detail of Ruby but does not affect how the 
language works.

>> Kind regards
>>
>> robert
>>
> Likewise squared ;)

Raised to the power of three. :-)

	robert