passing by refference

[Joshua Marshall]

Tim Peters <tim.one at comcast.net> wrote:
> [Fredrik Lundh, quotes the CLU reference manual, which has an excellent
>  description of call-by-object/call-by-sharing, in particular being
>  careful to distinguish it from call-by-value and call-by-reference
> ]

>> ...
>> So what's your excuse for being stuck in the early seventies? ;-)

> "call by value" is very often used in the Scheme world to mean "applicative
> order evaluation" aka "eager evaluation", which the Scheme standard mandates
> (as opposed to lazy evaulation schemes, such as Haskell's call-by-need).
> The Scheme standard itself didn't introduce this abuse of terminology, but
> it's catchy if it's a distinction you need to make often; in the functional
> language world, it is a distinction that needs to be made often.

I agree this is a misuse of the term "call-by-value".  There are
certainly langauges which both employ eager evaluation and
call-by-reference (eg. C++ can).

> So it goes -- believe it or not, sometimes different people mean
> different things by the same words <wink>.  The business of warping
> "call by value" to mean "the internal address of the object is the
> value" doesn't seem common even in the functional world, though.

It's only here that I disagree with you.  I consider Python values
themselves to be object references, which are simply copied/assigned
to the formal parameters upon function invocation.

Where I do agree with you is that it's an implementation detail that
these object references are implemented as C pointers.  For example,
(in a 32-bit world) small integers could be stored in the first 29
bits of a word, leaving three tag-bits to be used as a discriminant
(depending on the value of the discriminant, the first 29 bits might
represent an integer, an 8-byte aligned pointer, a 3-byte string, an
index into a repository of objects, or whatever you'd like).

Ok, enjoyable conversation, but I think we're starting to retread old
ground.