anything like C++ references?

[Erik Max Francis]

Stephen Horne wrote:
> 
> On 15 Jul 2003 10:19:18 GMT, kamikaze at kuoi.asui.uidaho.edu (Mark
> 'Kamikaze' Hughes) wrote:
> 
> >> Really. My computer science lessons were taught in a way that
> >> respected the source of most of the theory in mathematics -
> >> algorithms, Church's lambda calculus and that kind of stuff.
> >> What did your lessons teach?
> >
> >  How computer programming actually works, how to make interpreted and
> >compiled languages, how to use them to solve problems, how to analyze
> >algorithms, etc....  The usual.
> 
> You say that as if it contradicts the idea of respecting the source of
> the theory. It doesn't.
> 
> >  Among those were classes in languages
> >other than C, which is very broadening, and I highly recommend that to
> >you.
> 
> Lets see.
> 
> Probably about a dozen basics, five assembler languages (6502, z80,
> 68000 series, 8086 series, 80C196KC microcontroller), forth, lisp,
> prolog, miranda, haskell, icon, ada, pascal, modula 2, cobol,
> smalltalk. Not all of them very seriously, though, and in many cases
> not recently.
> 
> I forget the name of that language designed for transputers, but I
> used that a bit at college too - and depending on your inclination you
> may want to include SQL. And yes, I have used C, C++ and Java as well.
> 
> That's just off the top of my head, of course.
> 
> But there's no way you can call me C centric. That has been a repeated
> accusation, but it is WRONG.
> 
> Python has been an everyday language for me LONGER than C++ has.
> 
> >> Respect the idea of variables binding to values and suddenly the need
> >> for pointers becomes more obvious. You cannot abuse mutable objects to
> >> fake pointer functionality (another everyday fact of Python
> >> programming) if the binding of variables to values (rather than just
> >> objects) is respected.
> >
> >  If you're trying to say that the trick I showed you of modifying a
> >list to reproduce the effect of reference arguments is not possible in,
> >say, C, you're wrong.  Trivially proven wrong, even, since Python is
> >implemented in C.  In fact, the only languages where that won't work are
> >those which don't allow passing complex arguments at all; some
> >pure-functional toy languages, perhaps.
> 
> Distorting what I said, again. I have already repeatedly said that the
> point about C is what happens by default - not what happens when you
> explicitly request otherwise.
> 
> Lets take an example from C++ to illustrate the point.
> 
>   std::string x = "123";
>   std::string y = x;
> 
>   //  At this point, in most implementations, x and y are bound to the
>   //  same object due to a lazy copy optimisation. However, the
>   //  programmer didn't request this optimisation so this
>   //  implementation detail is expected to be transparent to the user.
>   //  Therefore...
> 
>   y [2] = 4;
> 
>   //  Before doing this operation, a copy was made - the so called
>   //  copy on write.
>   //  The value bound to x is still "123"
>   //  The value bound to y is now "124"
> 
> C++ is using references here just as Python does, but despite being a
> crappy low level language it still manages to implement that without
> causing remote side-effects through mutability *unless* you explicitly
> request that.

But (ignoring for the moment Tom's point about this not really being
true in modern implementations) that's really an implementation detail
and is unimportant.  C has copy semantics; whether it's optimizes some
away when they're not necessary is an implementation detail that is
unimportant from the programmer's perspective.

I did something very similar in a stack-based language I designed (and
implemented partially in C, and then more extensively in Python).  There
are no pointers or references, only objects.  All objects are distinct;
changing one never affects any others.  But since this is a stack-based
language, there's lots of duplicating things on stack for the purposes
of a computation.  As an implementation detail (and since I basically
got it for free in Python since all Python objects do the reference
counting for me), if you duplicate an object, I actually duplicate a
reference to it internally.  If you mutate an object, then it mutates it
if there are no other references to it, but does an actual duplication
and then mutates that if there are -- so it implements lazy copying. 
But the fact this is done at all is completely and utterly and
implementation detail.  From the programmer's point of view, it makes no
difference.

Python does _not_ have copy semantics, it has binding semantics.  As a
reversed example, when multiple bindings exist to the same immutable
object, it's an implementation detail whether or not those really are
all to the same object.  You don't care, because you know its value
can't change.

-- 
   Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
 __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/  \ Nine worlds I remember.
\__/  Icelandic Edda of Snorri Sturluson