I'm wrong or Will we fix the ducks limp?

[Steven D'Aprano]

On Wednesday 08 June 2016 17:53, Antoon Pardon wrote:

> Python could go the simula route, which has two kinds of
> assignment. One with the python semantics and one with C
> semantics.
> 
> Let as use := for the C sematics assignment and <- for the
> python sematics assignment. We could then do something like
> the following.
> 
> ls := [5, 8, 13, 21]
> a <- ls[2]
> a := 34
> print ls  # [5, 8, 34, 21]

What you seem to be describing is similar to reference parameter semantics from 
Pascal. Assignment doesn't work that way in C, or Python. In C, pointers can be 
used to simulate those semantics, but you have to explicitly dereference the 
pointer when you assign.

Using C assignment, with an array:

# excuse any minor syntax errors, my C is rusty
int A[4] = {5, 8, 13, 21};
int n
n = A[2];
n = 34;

the array A does not change. Assignment *copies* the value into the variable. 
To get the semantics you are after, you need to use a pointer with an explicit 
dereference:

int *p;
p = &A[2];
*p = 34;

which will now change the value of the array. If you leave the dereference out:

p = 34;

you are setting p to point to address 34, whatever that is.

Now, the point is, in order to deserve the term "first class", you the 
programmer shouldn't have to care about manual dereferencing. In C, you do, so 
while you can get "reference variables" in C, they're only third class. In 
Pascal, they're second class, because you can get reference variables but only 
for function/procedure parameters. Pascal doesn't generalise that to allow 
references to any arbitrary variable.

And of course Python doesn't have reference variables either. There is nothing 
you can do in Python to get this effect:

a = 1
b = a
b = 99
assert a == 99


although you can almost fake it using lists:

a = [1]
b = a
b[0] = 99
assert a == [99]


-- 
Steve