passing by refference

[Jordan Krushen]

On 15 May 2003 23:31:53 GMT, Donn Cave <donn at u.washington.edu> wrote:

Firstly, I'm no expert, but I believe I can help people understand this 
conversation better.

> Quoth Doug Quale <quale1 at charter.net>:
> | "Fredrik Lundh" <fredrik at pythonware.com> writes:
> ... [ quoting account of CLU system (by Barbara Liskov?) ]
> ...
> |>     Objects that do not exhibit time-varying behavior are called
> |>     _immutable_ objects, or constants.  Examples of constants are
> |>     integers, booleans, characters, and strings.  The value of a
> |>     constant object can not be modified.  For example, new strings
> |>     may be computed from old ones, but existing strings do not
> |>     change.  Similarily, none of the integer operations modify the
> |>     integers passed to them as arguments.
> |
> | Same as Scheme and Lisp except that strings are mutable in those 
> languages.
>
> What does ``the value of a constant object cannot be modified'' mean?
> Is it possible that by "value", the author means the computer data
> represented by the object?

The *value* of a *variable* is an object.
The *value* of an *object* is the above 'computer data'

Variables can be modified (rebound) -- they can reference new objects
Immutable *objects* are, in fact, immutable -- their contents (computer 
data) cannot be changed.
Several variables can reference the same *object* (ie have the same 
*value*)

This explains the following well-known idiom:

>>> l1 = [1,2,3]		# assigns [1,2,3] to an object, assigns that object to l1
>>> l2 = l1			# assigns above list object to l2 as well
>>> l1[1] = 'ni'		# modifies object's value (computer data)
>>> l1			# l1's *value* is still the list object
[1, 'ni', 3]		# 	this displays the *object's* value
>>> l2			# l2's *value* is still the list object
[1, 'ni', 3]		# 	this displays the *same object's* value

One would argue that the *value* of both l1 and l2 is the same object.  If 
one were to now write id(l1) and id(l2), they would be identical (at least 
they are to me).  The *value* of that *object* is [1, 'ni', 3].

I think most of the problem here stems from the fact that when assigns 
'computer data' ([1,2,3]) to 'l1', one doesn't necessarily see that it's a 
two-step process -- object creation, and object binding.

I don't think anyone would disagree that calling f(x) passes the object 
bound by x to f().  Ignoring under-the-hood implementation, this is how it 
effectively gets used by the Python programmer.  The problem is the 
semantic difference -- that the 'object bound by x' is seen by many to be a 
pointer of sorts, and thereby a reference.  The catch is that the 'object 
bound by x' is the same thing as the 'value of x'.  The 'value of the value 
of x' would be the actual computer data.

People seem to forget that a variable is a reference to a reference of 
actual data.  There's an object in the middle, which is the rvalue of x.  
This *value* gets passed to functions, which, under-the-hood, expand it to 
determine the actual 'computer data' held within.

Am I correct in understanding that this is why Doug is calling it CBV, and 
others are calling it CBR?  The fact that f(x) does not send a reference to 
x, but the value of x, which is itself a reference of sorts?

J.