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

[Delaney, Timothy]

This could get complicated to understand, so I'm going to use some examples
...

If a reference is bound as a result of being assigned a reference with
mutable access to an object, the new reference has mutable access.

If a reference is bound as a result of being assigned a reference with
immutable access to an object, the new reference has immutable access.

The immutable() function and immutable keyword can change the access of a
reference being assigned to immutable.

There should also be a mutable keyword for function declarations, but not a
mutable() function. This would throw an exception if a reference is passed
which has immutable access. Basically, this is saying that the contents of
the parameter *will* be changed.

# var1 becomes a reference to a list with mutable access
var1 = []

# var2 becomes a reference to the same list, with immutable access
var2 = immutable(var1)

# var3 becomes a reference to the same list, with immutable access
var3 = var2

# the following operation will throw an exception
try:
	var3.append(1)
except ImmutableException:
# the following line will be reached
	pass

# var3 becomes a reference to the same list, with mutable access
var3 = var1

# the following operation will not throw an exception
try:
	var3.append(1)
except ImmutableException:
# the following line will not be reached
	pass

# var4 may have either mutable or immutable access
def m_or_i (var4):
	return var4

# var5 will always have immutable access
def i_only (immutable var5):
	return var5

# var6 must have mutable access or an exception will be thrown
def m_only (mutable var6):
	return var6

# var3 becomes a reference with mutable access
var3 = m_or_i(var1)

# var3 becomes a reference with immutable access
var3 = i_only(var1)

# var3 becomes a reference with immutable access
var3 = m_or_i(var2)

# var3 becomes a reference with immutable access
var3 = i_only(var2)

# var3 becomes a reference with mutable access
var3 = m_only(var1)

# an exception will be thrown and var3 will be unchanged
var3 = m_only(var2)

Tim Delaney
Avaya Australia
+61 2 9352 9079

> Timothy,
> 
> Thank you very much.  I played around with Python a bit and then
> this started making sense to me. 
> 
> How would immutable work for return values? anything special there?
> 
> Roey
> 
> 
> On Wed, 13 Dec 2000, Delaney, Timothy wrote:
> 
> 
> > 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).
> > 
>