anything like C++ references?

[Adam Ruth]

Stephen Horne <intentionally at blank.co.uk> wrote in message news:<9mh6hv45v18apgn6lp7bo6mm63e5oba9rd at 4ax.com>...
> >You say that there is one gold standard definition for what a variable 
> >is.  Yet even though C++ deals with variables in three semantically 
> >distinct way, they are somehow all valid within that definition?
> 
> C++ does not deal with variables in three semantically distinct ways.
> It provides a wide range of data types (including pointer types and
> reference types) and, in keeping with the mathematical concept of an
> abstract data type, each has both its own set of values and its own
> set of operations. The only way in which semantics vary from variable
> to variable is in that some of those semantics are tied to the
> abstract data type.

I was going to stay out of this thread because we were just retreading
the same ground with different wording, and it was pointless.  But
here you've brought up something that is completely false, and new to
the discussion:

> C++ does not deal with variables in three semantically distinct ways.

You're correct, it deals with variables in more than three
semantically distinct ways.  Now, semantic may mean something
different to you than it does to me, but if I have two variables and I
cannot use the same syntax with each, they're semantically different. 
Let's look at some of the differences.

int i = 1;
*i = 5;

Does this work?  No, it doesn't, because pointers are semantically
different than non pointers.

register int x = 5;
int *y = &x;

This also cannot be done.  Why?  Different semantics for register
variables.

int y = 1;
int x = 2;
int &m = y;
m = x;

Now, here are two problemmatic things.  1)  References are just
pointers with syntactic sugar, right?  Well, it's a pretty thick layer
of sugar.  Not only can't you use * to dereference, but you don't use
& to get the reference, and you don't use -> to access members. 
References are in the netherworld between pointers and regular
variables.  In some cases they act like variables, in others they act
like pointers.  Now that's confusing.

2) C++ makes a strong distinction between the initialization operator,
=, and the assignment operator, =.  Both const and reference variables
use them differently.  To me, that's a really big violation of proper
'computer science', because conceptually they're the *same* thing. 
But because of context, C++ makes a distinction.  Python has no such
distinction, initialization and assigment are always the same.

(This is true of all static languages with the concept of a constant,
and I don't really disagree with it as a valuable idiom, but it is
inconsistent internally, where Python is consistent.  Do any languages
use a different operator for initialization?)

Now here's one that's very germain to the topic:

void mod(char *value) { value[0] = 'a'; }
char *str = "hello world";
mod(str);

What about this one?  str is immutable (or more accurately, its value
is immutable).  How does mod know this?  It doesn't, it's a seg fault.
 Now, not only is str immutable, but its not inferrable at any point
within the function (I guess you could look at it's region in memory,
but then you're really down at the implementation layer).  Does this
violate 'computer science' principles?  I'd say it violates the
principles you've put forward.


> Even when using pointers, the binding of variables to
> values is preserved. It is merely that pointer values provide an
> indirect way of referencing a store location, or placeholder, which
> may be manipulated (ie bound to a different value) using some other
> means of identifying that placeholder.

The only real difference between this and Python is that in C you're
looking at a region in memory that is most always mutable.  Python
doesn't need to follow this idiom to be correct.  Why?  Because Python
doesn't have regions in memory, it's a non-existent concept.  In C you
have variable -> memory -> value.  In Python you have variable ->
value.  You may not like this, but I don't think you can correctly say
that the C way is 'better' or 'more in line with computer science'. 
And it certainly isn't more confusing, that's a crock.  What you need
to know to work with variables in Python is a much smaller base of
knowledge than what you need to work with C++.  To you it doesn't seem
that way, because C++ is second nature to you.  But if you took two
novice programmers and tried to explain both ways, the persion
learning Python would 'get it' much sooner, because there's much less
to 'get'.

All I have to do is think about the blank stares I get when I try to
teach a new programmer about pointers.  It's a difficult concept to
get, and it's difficult mainly because you need to understand
implementation to get it, something you constantly accuse Python of. 
In C++ you *need* to know implementation of pointers, references, etc
to be effective.  And you will be surprised quite often by confusing
and unexpected semantics and behavior.  That just doesn't exist in
Python, when I make an assignment, I *know* what's going to happen.

And even if C++ is more 'correct' from a computer science standpoint,
Python is more simple, concise, and consistent.  I'll take that any
day.

Getting back to the original topic of the discussion, pass by
reference.  There's a very, very good reason Python doesn't do it:
It's not necessary.  It only exists in C and C++ to overcome
limitations in both languages.  Those limitations *don't* exist in
Python, so there's no need for pass by reference.  There is no example
of a situation where pass by reference is the only way to do things,
in fact, the way that Python works allows for much *better* ways to
achieve those goals.  It's simply unnecessary.