anything like C++ references?

[Stephen Horne]

On Sun, 13 Jul 2003 17:16:55 -0400, Jack Diederich
<jack at performancedrivers.com> wrote:

>On Sun, Jul 13, 2003 at 03:05:38PM -0500, Ian Bicking wrote:
>> On Sun, 2003-07-13 at 14:39, Stephen Horne wrote:
>> > The fact is that 'assignment' has a common meaning separate from the
>> > choice of programming language, 
>> 
>> This just isn't true.  The C++ assignment operator is not at all like
>> the Python assignment statement.  Python variables are not like C++
>> variables, no surprise assignment is different too.  If you used
>> languages outside of C++ and its like (e.g., Pascal), you would find
>> Python's behavior common.
>> 
>
>C++ is the only language that has the same semantics as C++.
>
>I was a long time C++ guy and my a-ha moment was when I realized that the
>GoF's "Design Patterns" were not all universal -- some are C++ specific.
>Trying to force Python semantics into a C++ world view will leave you feeling
>empty every time.  Drink the koolaid, python has a short learning curve.  
>If this is a problem - whatever you do - DONT TRY TO LEARN LISP.
>
>If you want a more polished C++, use Java.  Python is in a different class
>of languages.

Java has the same problem as Python in this respect. You can either
state that it implements a different assignment semantic for some data
types than it does for other data types, or you can claim that some
data types have implicit built in references while others don't.

The Java rationale is essentially that 'pointer' is considered a dirty
word, so it was considered necessary to disguise them in Java. End
result - you have to use things which are not pointers as if they
were. You have to abuse data types in an arbitrary, confusing and
error-prone way in order to create the effect of pointers/references.

In Python, Guido describes his rationale for the existence of both
mutable lists and immutable tuples here...

http://www.python.org/search/hypermail/python-1992/0292.html

According to this, the benefit from an immutable tuple is that there
is no immediate copy, yet the tuples stored in the object are
protected from accidental 'mutation'. It allows a lazy copy-on-write
optimisation combined with preventing unwanted mutation of those
tuples. ie Guido justifies the need for an immutable tuple in terms of
copying - the rationale is about assignment, even though the effect is
the same as in Java in which the rationale is about disguising
pointers.

Note that Guidos rationale assumes a tie between the concepts of
'reference to value' and 'in place modifiability of part or all of
value'. This is bogus - these are two different concepts. There is no
reason why mutable objects shouldn't be assigned using copy-on-write
semantics, and there is no reason why there shouldn't be a simple
reference or pointer data type which has the explicit purpose of
providing indirect reference to single values of any type whether
mutable or immutable.

The only 'trouble' is that it suggests a need to distinguish
assignment to a variable (replacing the previous value even if it was
a pointer) from assignment to a pointed-to location. In fact you
already do this if you fake pointer functionality using mutable
objects, the only difference is that a pointer dereference is specific
to the real purpose and does not require abuse of data types that are
designed for other jobs.

People may say that pointers are bad news, but that impression
resulted from languages like C and Pascal and it should be qualified
in two ways. Pointers in C and C++ are dangerous in a very important
way. Pointers don't always point to a valid object - they may point to
something that was deleted, for instance. This is worse in the C
family as pointers and arrays are almost treated as the same thing,
and array subscripting has no bounds checking. Furthermore, there is
the risk of memory leaks.

If pointers always point to a valid object (except, perhaps, a special
pointer-to-none value which throws an exception on dereferencing), if
pointers are kept distinct from other abstractions such as arrays, and
there is no possibility of accessing whatever memory happens to be
beyond the bounds of some particular type, and if garbage collection
is used then the only reliability objections that can be levelled at
pointers would relate to code complexity - and that complexity can
only be increased by faking pointers using mutable types designed for
other tasks. All of these are perfectly plausible for a scripting
language.