anything like C++ references?

[Stephen Horne]

On 14 Jul 2003 07:25:31 +0200, martin at v.loewis.de (Martin v. Löwis)
wrote:

>Stephen Horne <intentionally at blank.co.uk> writes:
>
>> >>>> a = ref(1)
>> >>>> b = a
>[...]
>> >>>> a = 5
>> >>>> b
>> >5
>[...]
>> Well, during the 'debate', that's the basic idea that involved -
>> except that I'd use explicit pointer-dereferencing syntax.
>
>This is a very bad idea. You want to create a reference to the object
>1? Then I assume that assigning to "a" would *change* the value of 1?
>But 1 is an immutable object, it cannot change!

That is NOT what I said.

I was saying that the basic idea is right, not the notation expressing
it. I want pointers to be explicit as a data type.

Besides, in my mind the notation...

>> >>>> a = ref(1)

...creates a reference to an object which is initially bound to the
value 1 and binds that object to the variable a.

Variable a bound to anonymous object.
Anonymous object bound to value 1.

Reassigning to that object would merely rebind that object to another
value. Immutability of values is preserved. Immutability of objects is
not the same thing.

Not my favoured notation, and of course I left Ians explanation of the
problem with that notation quoted.

>> Imagine, for instance, changing all assignments and other 'copying' to
>> use a copy-on-write system. 
>
>That assumes that there is the notion of copying values in the first
>place. Objects, in general, don't support copying - and assignment has
>nothing to do with copying.

That is why 'copying' was in quotes. I merely wanted to indicate that
parameter passing and such was included.

>> >>> a = &5
>> >>> b = newcopyof a        #  could be "b = &(*a)" in principle
>> >>> *b is *a
>> False
>
>Again, objects don't support copying. For immutable objects (like
>numbers), copying is also a pointless operation: If there where a
>standard .copy method on objects, numbers would return themselves.

You miss the point. Though it's partly my fault for a stupid mistake
("b = &(*a)" would not copy the object that *a refers to, it would
merely rederive the pointer which is rather pointless).

It isn't about copying the value. It is about copying the
representation of the value, or the object that is bound to that
value.

The fact that some objects can't be copied would simply become
explicit and obvious. People couldn't end up thinking they are dealing
with a separate copy just because they have two variables bound to
that object. They couldn't have two variables bound directly to one
object. They would either have to explicitly use pointers, or
explicitly copy the object - and the latter wouldn't be possible for
objects that don't support copying.

Straight off, a common cause of confusion and errors would be removed.

Write...

  x = classname()
  y = x

... and that would be an error. Although it wouldn't need a copy at
that point, it implies the need to copy as soon either variable is
used to make a change to the object.

However...

  x = &classname()
  y = x

... and everything is fine. Both variables have been *explicitly*
linked, via pointers, to the same object. There is no need to copy the
object.

Actually, there is an implementation issue there. 'x = classname()'
does do an assignment, after all. It's only safe because copying of
the object is avoidable. This claim can also be made of the second
case - that claim only breaks down when that object is mutated by an
access via one variable or another. A little fiddly, but not that
difficult to fix. If each object knows how many times it is directly
referenced (either by a variable, or by what I'll call a 'register' in
expression evaluation) it can detect problems. It would have to do
something similar, in fact, to do the copy-on-write when copying is
implemented.

This is something that C++ also gets wrong, IMO, because classes get
copying operations (assignment, copy constructor) by default unless
you do something to stop them. A shorthand for requesting a naive copy
when appropriate seems better to me.

>There is no way, in the language, to express that you want different
>copies of the value 5.

No - I was talking about a language change, and I was talking about
copying representations.

I want to be able to assume that the language implements binding of
variables to values. I want a datatype that allows me a way of
indirectly referencing objects - pointers, in other words.

If I write...

>>> a = 5
>>> b = newcopyof 5
>>> *b = 6

I don't expect the variable a to be affected. I have not changed the
value 5 into the value 6, I have merely changed the value that is
bound to an object. That object was created by copying another object,
but that doesn't mean all objects have to be copyable.

> This is completely different from the notion of
>values in C or C++, where each occurrence of the literal 5 creates a
>new value whose state is 5.

Not true. Each occurence of the literal 5 creates a new 'symbol' which
represents the value 5. The immutability of values is preserved in
C++.