Label-Value (was: Re: Inheriting the @ sign from Ruby)

[Delaney, Timothy]

> > (Hint: Everything is a reference to an object.  Variables are
> > named references, not actual objects.  Some objects can be
> > modified in place.  Some cannot be modified.  That's all)
> 
> Okay! tell me, which are the objects which cannot be modified 
> in place? I
> assume these are int's, long's, float's, etc.  Strings, 
> lists, objects and
> dictionaries are call-by-reference.  Pardon my choice of 
> diction, but I am
> against inventing new terminiologies (modified-in-place??). 

Objects are generally documented as mutable or immutable. As an example:

	tuple is immutable
	list is mutable

In both cases, you can pass a reference to the object to a function. The
function aquires a *separate* reference to the object.

Now, if you assign something else *to that reference* you change what that
reference is referring to. When you exit the function the original reference
still refers to the original object.

However, you can modify the contents of the list that the reference is
referring to. In this case, the contents of the object that the original
reference is referring to (which is the same object as the reference in the
function is pointing to) will change.

If you try to modify the contents of the tuple that a reference is referring
to you will have an exception thrown, because it is immutable.

Likewise, you pass around references to other immutable items such as
integers. The difference is that they are immutable *and* they don't have
"contents" as such. You can change object the reference to the integer is
pointing to, but every other reference to that integer remains unchanged.

Note: you list string as "call-by-reference". Yes, it is. However, you can't
modify the contents of a string (they are immutable). You can assign a
different string to the reference - but the original reference still points
to the original string.

> I want to know where this is documented.  Specifically, where is the
> dichotomy of ints/longs/floats vs. 
> objects/strings/lists/dictionaries. 

There is no dichotomy. Everything behaves the same.

You appear to be thinking of python in C terms. In this case, consider
python references as pointers. You *only* pass pointers. Some of these
pointers may point to a const memory location. Some don't. If you change
what a copy of the pointer is pointing to, you don't change what the
original is pointing to. If you change the contents of the memory location
is that is being pointed to, dereferencing any pointer which points there
will expose the change.

> While I'm brainstorming with Python grammar changes, what 
> about a real &
> operator.  No more of this hokey is-it-modifiable-in-place-or-not
> business.  Explicit control is important. 

IMO there should be an explicit immutable() function and an immutable
keyword.

The function would return the original object, but mark it as immutable
(thus, you could simulate tuples by calling immutable() on a list).
Attempting to modify such an object would throw an exception.

The keyword would be used to mark parameters to functions.

Note that the immutability would be based on *which reference you accessed
the contents through*. Thus you could have a multi-threaded app which has
one thread with a mutable reference, and all the others with immutable
references. Suddenly you don't need to worry about locking an object to
write to it!

In both cases, I envisage that it would go from one dictionary holding
references in each namespace, to two - one for references to immutable
objects, the other holding references to (possibly) mutable objects (i.e.
any which have not been marked as immutable).