Qualified appology (was Re: anything like C++ references?)

[Stephen Horne]

On 14 Jul 2003 11:44:02 -0700, owski at hotmail.com (Adam Ruth) wrote:

>Stephen Horne <intentionally at blank.co.uk> wrote in message news:<1br3hv4434gn7p2pdg1bgtg8dtlak3id3s at 4ax.com>...
>> I've said my piece on meanings derived from computer science (and in
>> turn from mathematics, as it happens - variables as placeholders for
>> values predate electronic computers by quite some time.
>
>The mathematics I'm used to has a very different concept of assignment
>than does a static language like C.  Here's why.
>
>In math there are global unchanging objects called numbers, 1, 2, 3,
>etc.  If I have 2 variables, x and y and they both equal 500, then
>they both are names bound to the value 500.  They are not each copies
>of the value 500, math has no such concept, there is only one 500.

Yes.

Mathematics does have assignment - it had assignment long before
electronic computers existed because algorithms were a concept studied
in mathematics long before computers existed.

If in mathematics, if I have one variable a defined as representing
the set {1, 2, 3} and a variable y also defined as representing the
set {1, 2, 3} and I decide to change y to {1, 2, 4} then that
redefinition process does not change the value {1, 2, 3} to {1, 2, 4}.
It only changes what the variable y is currently taken to represent.

Values cannot be mutable in mathematics.

In Python, *objects* can be mutable. Values cannot be mutable because
they are values - something defined in mathematics. 1 cannot become 2.
But a variable can be reassigned to represent something else. In-place
modification of part of an object is a practical way of replacing one
value with another.

Thus, if I write...

>>> a=[1,2,3]
>>> a[2]=4
>>> a
[1, 2, 4]

Nothing is wrong. The in-place modification of part of the object that
a is bound to is basically a convenient shorthand for reassigning the
whole value of a. The value now bound to a is [1, 2, 4] rather than
[1, 2, 3]. No value has mutated. Nothing is wrong in mathematical
terms. The fact that we are using something called an object (or a
pointer to an object or whatever) to implement the binding to a value
is unimportant.

>>> a=[1,2,3]
>>> b=a
>>> b[2]=4
>>> b
[1, 2, 4]
>>> a
[1, 2, 4]

Because the variable b has been bound to an object (*NOT* a value),
the mutation has a side-effect. Changing the value bound to the
variable b also changes the value bound to a. This does *NOT* happen
in mathematics, because there is no such thing as an object.

Reassigning one variable in mathematics never implicitly redefines
another.

In short, this no longer implements a binding of values to variables
because of the side-effect of changing the value bound to a when you
change the value bound to b. The implementation detail of how the
binding from variables to values is achieved (by binding to objects)
has changed the results of running the algorithm.

In a true functional language, variables are not mutable. It doesn't
matter in the slightest if binding of variables is handled by copying
pointers to objects instead of copying objects - it is irrelevant
because copying pointers to objects achieves exactly the same thing as
copy the objects themselves - it implements a binding of value to
variable.

The object bound to a variable in Python is a low-level implementation
concept. From Guidos own words, we can see that he (at least at one
point) recognised that binding to objects in a context where those
objects can be mutable is confusing and error-prone.

The value bound to a function in mathematics is a high-level concept.

I thought Python was *supposed* to be an very high-level language?

Even C++ is higher level that this. The C++ standard libraries I've
used will optimise assignment of strings by merely copying pointers.
The sequence of events you get is something like this...

  std::string x ("Hello");
    //  x bound to object containing value "Hello"

  std::string y (x);
    //  y bound to same object as x, but with an indication that
    //  sharing is happening.

  y [4] = '!';
    //  A write to y, with the purpose of changing the value that y
    //  is bound to but not changing the value that x is changed to.
    //  Thus a copy of the object containing "Hello" is made and
    //  bound to y before applying the change. This is called
    //  copy-on-write.

In short, C++ can and often does use the pointer-copying optimisation
in the standard library. But it does so in such a way that the low
level binding of variables to objects implements the high level
binding of variables to values correctly.


It is clear now that many people are highly committed in the binding
of variables to objects done in a way that does not implement binding
of variables to values - though there seems to be fuzzy thinking used
against me just as much as my own fuzzy thinking earlier. For
instance...

On 14 Jul 2003 07:39:57 +0200, martin at v.loewis.de (Martin v. Löwis)
wrote:
: And so does mine: Variables are *not* containers of values, in
: traditional mathematics. They are bound to values instead.

Python does not bind values to variables. It binds objects to
variables. Objects are how values are implemented, but they are not
the same thing.

In computer science and mathematics, the whole point of variables is
to bind a variable to a *value*. Terms such as 'store location' and
'object' are about *implementing* that binding from variable to value.

In mathematics, it doesn't matter whether you talk of variables being
placeholders for values or whether you talk of them being bound to
values. The two are equivalent, because mathematics has no concept of
objects as an implementation detail. Both terms are in common use.

In support of this, I quote someone arguing against me...

On 14 Jul 2003 11:44:02 -0700, owski at hotmail.com (Adam Ruth) wrote:

"""
C, and most static languages, have the concept of memory location,
which doesn't exist in math.  In C a variable is bound to a memory
location which contains a value, not like math where the variable
itself contains the value.  Therefore I can have two variables, x and
y, that point to their own distinct copy of 500 and when I assign a
value, it copies the 500 into the memory location bound to x.
"""

"not like math where the variable itself CONTAINS the value"

In addition, note that C++ does not copy the value. It copies a
representation of the value. Thus when you say two variables contain
"their own distinct copy of 500" what you are really saying is that
two variables contain "their own distinct copy of a representation of
the value 500". That is why you can use the operator '==' to test if
two variables contain the same value - or rather in-store
representations that represent the same value.


"""
In math there are global unchanging objects called numbers, 1, 2, 3,
etc.  If I have 2 variables, x and y and they both equal 500, then
they both are names bound to the value 500.  They are not each copies
"""

No - they are not objects, or store locations. They are global
unchanging values. And yes, variables *are* bound to values - *not*
objects.

"""
Python is more like the math form.  There is only one instance of the
number 500 and a name (variable) is bound to it or it isn't.  To
change the value of 500, then I must rebind the name, exactly in
mathematics.  However, Python differs from math in that math doesn't
have mutable values (well it may when you get into real complex
calculus, I don't know, never been there).
"""

Mutable values don't exist at all. Mutable objects do. When you mutate
a part of an object, that object now represents a new value.

Its a shorthand in Python for something that is perfectly valid in
mathematics - but not if the binding of other variables to values is
affected.

BTW - "real complex" is a contradiction in terms ;-)


Anyway, if you so love your variables binding to objects done in a way
that does not correctly implement variables binding to values for
mutable objects, fine. It simply means that Pythons users have to fuss
about the implementation of Python instead of getting on with their
applications logic, and that it will continue to cause confusion and
errors on an ongoing basis.