«

On 14 Jul 2003 10:26:36 -0400, (Aahz) wrote:

>>>That's why I (and others) prefer to use "name" and "target" instead of
>>>"variable". Would that assuage your ire?
>>
>>Not really, for reasons defined elsewhere. The problem isn't
>>theoretical - it is practical, as shown by the fact that people do
>>trip over it time and time again. I'm just saying that the problem
>>arises out of peoples intuition of how variables should work - an
>>intuition that matches very well with theory.
>
>People trip over pointers, too, even when they're explicit. Heck,
>people have problem with the simple
>
> a = a + 1
>
>no matter *what* programming language is used if they can't get past
>their high school algebra and understand that "=" is a *command* in this
>context. The question is not whether newcomers get tripped up, but the
>extent to which the language can be easily defined in a consistent and
>rigorous manner. Python passes that test quite handily, IMO.

Ah - but this is also Pythons fault. It has arbitrarily redefined the
meaning of a mathematics operator - presumably simply because C, C++,
Java, Basic and others have done this in the past.

C's rationale for this still amuses me. It was because there are more
assignments in a typical program than tests for equality. It was an
argument about numbers of keypresses!

Frankly, this is another thing that should not be done in a 'very high
level language'.

In BASIC, the operator is a shorthand for what was originally written
with a 'LET' command. Annoying, but at least the original form made
the point.

Personally, though, I'd go with Pascal on this one.

Similarly, if Pythons binding of variables to objects was used to
correctly implement a binding of variables to values - as happens in
mathematics - there'd be no confusion.

In another thread, hokiegal99 made a mistake where she expected the
string.strip method to literally change the name of a file on disk.
But was she being irrational? I don't think so. She had no doubt been
told, in effect, that Python variables bind to objects rather than
values. The object she was changing was 'the name of a file'. If
Python variables bind to objects rather than values, then that os.walk
method should be providing literally a list of the names of the files
- objects which literally refer back to the on disk file names. It
doesn't. It provides a list of representations of the names at a point
in time.

Of course in this case, binding to the object itself (or something
that implements a binding to that object) would be complex and
inefficient. I guess Python is just doing what is convenient for the
implementation.

On 14 Jul 2003 07:56:40 +0200, (Martin v. Löwis)
wrote:

>Stephen Horne <> writes:
>
>> Funny thing. When I use algebra, the variables I define don't end up
>> referring to different values, functions or whatever unless I
>> explicitly redefine them. When I write a definition on one piece of
>> paper, the things I wrote earlier on another sheet don't change.
>
>That, typically, is because you don't have any mutating operations in
>your formulae. All functions you use are side-effect-free. If you
>translated the sheets of paper literally into Python, the formulae
>would work the way you expect them to work.

Funny. Algorithms in mathematics have been around much longer than
Python or even electronic computers.

Stephen Horne wrote:

> All you have proven is that it is the distinction between types
> that get re-bound and those that don't (rather than the use of
> references) that is unnecessarily confusing and error prone.

As the firestarter (I apologize for the flames that have
erupted), I must admit that even I know that this distinction
does not exist in Python. There aren't some types that get
rebound and others that don't.

def fn(arg):
local = SOME_GLOBAL
local = arg

local gets rebound to arg regardless of what the types involved
are, period.

> The wart remains, even if my description was wrong. And even that
> is a dubious claim.

I still feel that there's a wart of some sort, but it's not due
to any inconsistency in the language, despite what I may have
said before (I've been thinking about it a lot over the past few
days).

> A Python user is interested in how an object behaves - not how it
> is internally implemented in the interpreter. Immutable objects
> don't behave as references - the internal use of references for
> immutable objects is basically a lazy copying optimisation and,
> apart from performace and a couple of other technicalities (e.g.
> the 'is' operator), has no relevance.

Are they really technicalities, though? I mean, a mutable object
can be changed. It's the same object, just changed. Immutable
objects, however, can't be changed. You can get something that
appears like changing it, but it's actually building a new thing
and binding the label to that new thing.

What I specifically want is a way to have a "second-level
binding", e.g. a reference to a reference (assuming that the
terminology is correct by saying that all Python variables are
references). This is where I see the hole in Python, that there
actually is a class of object that is different from everything
else; you can bind to anything at all in the language...except
references.

-tom!

Stephen Horne <> wrote:
> Ah - but this is also Pythons fault. It has arbitrarily redefined the
> meaning of a mathematics operator - presumably simply because C, C++,
> Java, Basic and others have done this in the past.
> [...]
> Personally, though, I'd go with Pascal on this one.

Most languages have two "equals" operators, one means assignment, the
other means test for equality. Depending on the language, these are
spelled "=" and "==" or ":=" and "=" (or a few other variations).

The wierd thing is that I don't think either one really matches what a
mathematician means when he writes "=". In math, "=" is neither an
assignment or a test: it's an assertion.

On 14 Jul 2003 11:35:57 -0700, (Adam Ruth) wrote:

>Stephen Horne <> wrote in message news:<>. ..
>> On 13 Jul 2003 21:03:59 -0700, (Adam Ruth) wrote:
>>
>
>> C++ has precisely one type of variable. That variable is a placeholder
>> for a value of a datatype which is specified in the declaration. The
>> datatype may be a pointer datatype, but so what? Pointer datatypes are
>> not treated any differently than other datatype except that they, like
>> all datatypes, they have their own set of functionality.
>
>Granted. Pointers are no different than other data types, but they
>are typically used for operations that are semantically very different
>than other datatypes are used for. In that sense, they are, at a high
>level, different data types.

A different data type is nothing special. Mathematics has the concept
of abstract data types. That's the point. There's no need to invent
different kinds of variable, only different types of data. The fact
that C and C++ variables are restricted in the set of values they can
bind to (ie those with a particular data type) is not a problem.

>It's like how c programming is taught has having pass by reference and
>pass by value, when there is only pass by value at the implementation
>level. Pass by reference is a concept added on top of the language.

No. C programmers always pass by value. Sometimes that value is a
pointer.

Pascal programmers sometimes pass by reference. They do so explicitly,
however - using the keyword 'var'. There is a big difference between
*choosing* to have variables bound to an object, and having it happen
automatically whether you want it or not.

>> C++ references are tellingly also called self-dereferencing pointers.
>> They are not a distinct concept - they are syntactic sugar. I suspect
>> they mainly arise out of the modern desire to disguise pointers and
>> fantasize that they're not there, though they certainly work very well
>> in certain contexts.
>
>Syntactic sugar or no, they still behave differently than other
>datatypes and are therefore not consistent... IMHO.

They behave exactly like pointers. You just use different notation to
get that behaviour. That is what makes them syntactic sugar.

>> Funny thing. When I use algebra, the variables I define don't end up
>> referring to different values, functions or whatever unless I
>> explicitly redefine them. When I write a definition on one piece of
>> paper, the things I wrote earlier on another sheet don't change.
>>
>> Seems to me that the math equivalent of assignment (defining named
>> things) works very much like the 'static language definitions' as you
>> put it.
>
>The devil is in the details. Math assignment is static assignment is
>dynamic assignment. They really are all the same thing at a high
>level, but it's the implementation and the subtleties that make them
>vary.

Not true. Maths has the concept of an algorithm, and it has the
concept of assignment.

In maths, a variable binds to a value. In Python, a variable binds to
an object in a way that does no correctly implement binding to a value
unless the object happens to be immutable.

On Mon, 14 Jul 2003 19:17:59 -0400, Roy Smith <> wrote:

>Stephen Horne <> wrote:
>> Ah - but this is also Pythons fault. It has arbitrarily redefined the
>> meaning of a mathematics operator - presumably simply because C, C++,
>> Java, Basic and others have done this in the past.
>> [...]
>> Personally, though, I'd go with Pascal on this one.
>
>Most languages have two "equals" operators, one means assignment, the
>other means test for equality. Depending on the language, these are
>spelled "=" and "==" or ":=" and "=" (or a few other variations).

That's why I referred to Pascal.

>The wierd thing is that I don't think either one really matches what a
>mathematician means when he writes "=". In math, "=" is neither an
>assignment or a test: it's an assertion.

99 out of 100 times, true. But not always - especially in discrete
maths.

For example, if I write...

[forall] x . f(x) = y

It's hard to interpret that '=' as an assertion. Similar applies to a
range of maths operators.

Basically, the way I rationalise it is that when I see what looks like
a boolean expression standing on its own, I take it as an assertion
that that expression evaluates to true. I'm not saying that has any
mathematical validity, but it does seem to cover all cases.

So if I see...

x = 1

I take it as an assertion that the boolean test 'x = 1' evaluates to
true, and from that I can infer the value bound to x (or, in other
cases, infer some properties of that value).

Or rather I don't - but that's the rationalisation for what I do do.

Tom Plunket wrote:

> What I specifically want is a way to have a "second-level
> binding", e.g. a reference to a reference (assuming that the
> terminology is correct by saying that all Python variables are
> references). This is where I see the hole in Python, that there
> actually is a class of object that is different from everything
> else; you can bind to anything at all in the language...except
> references.

I just realized that this would be silly, complex, etc.

Say you could (as another poster mentioned) do something like
this:

>>> a = 5
>>> b = ref_to(5)
>>> a = 3
>>> print b
3

This would require a new built-in probably, and any time you
(accidentally?) did 'b = c', then you'd lose that reference,
but... hmm, I wonder if it'd be handy.

Probably not enough to justify the expense.

-tom!

On 14 Jul 2003 06:02:54 -0000, Moshe Zadka <> wrote:

>On Sun, 13 Jul 2003, Stephen Horne <> wrote:
>
>> The problem is that you are confusing implementation with semantics.
>> The meanings of 'variable', 'value', 'assignment' etc are defined by
>> computer science.
>
>This is not just wrong, but as far as it is right, the semantics agree
>with Python's
>In computer science, the theoretical model one first learns is a turing
>machine. Turing machines have no variables or values, merely tapes. While
>I'm sure you can creatively translate the terms to turing machiens, this
>exercise seems fairly pointless. Ram machines are similar. More abstract
>models, like recursive functions, deal with integers only, so again you
>would need hard to associate terms with them [you can implement a list
>of integers with the p_1^n_1*....p_k^n_k, where p_1,...,p_k are distinct
>primes. I'm not completely sure how this would translate to Python, though ]

Ever seen Euclids algorithm for the highest common factor?

Euclid was around somewhat before turing. Algorithms are a
mathematical concept. When you solve a quadratic equation by
completing the square, you are applying an algorithm for instance.

In maths, variables bind to values. Not to intermediate things that
implement or represent values. How Python implements its binding of
variables to values is its own business, but IMO if it merely binds
variables to objects - and does not correctly implement binding to
values using that mechanism - then it is behaving in a confusing and
error-prone way.

>However, computer science did have a minor notational revolution: Lisp.
>Lisp was originally invented as an abstract way to express computations
>in a more natural, and yet well-defined, way. The fact that lisp can be
>*implemented* was somewhat of a shock, but it turned to be a fairly useful
>language.

Funny. From what I recall of Churches lambda calculus, variables bind
to values. Changing the value bound to one variable does not change
the value bound to any other variable. After all, why would Church
worry about the details of implementation on a computer? He was a
mathematician. His ideas were developed in the 1930s, IIRC - they
weren't applied on computers until much later.

Lisp was created as a way of implementing Churches lambda calculus. In
doing so, some compromises were made due to the state of technology at
the time.

>[Note that in Lisp conses, for example, are actually mutable. However,
>many functions treat them as immutable objects. This is perfectly fine,
>and was a concious design decision in Lisp. Similarily, Python wouldn't
>*need* tuples: they can be implemented as lists. The immutability allows
>the implementation to play tricks with memory usage, though.]

No - mutability allows the implementation to play tricks with memory
usage. With immutables, Python binding of variables to objects
correctly implements binding of variables to values.

On Mon, 14 Jul 2003 23:38:56 +0000 (UTC), Adam Ruth
<> wrote:

>So, then, what makes a different variable type? If not different syntax
>and semantics, what would be the signature?

In the sense in which you said there were three types of variables in
C++, there are no different variable types. Pointer data types are
nothing special compared with any other data type.

Syntax and semantics vary from one data type to another, just as with
the mathematical concept of abstract data types. Nothing wrong with
that. In mathematics, an abstract data type is associated with a set
of values *and* a set of operations.

>Let me see if I understand what you're saying. Even though C++
>variables can have different syntax and semantics (depending sometimes
>on context), the're all really the same internally and are therefore
>perfectly consistent and usable.

Its not about implementation details. Its about respecting the binding
of variables to values - a high level concept from mathematics.
Binding of variables to objects is a low level implementation detail
in programming languages.

> Python variables, on the other hand (
>mutable and immutable) have somewhat different semantics (a debatable
>point) but identical implementaions (indeed, indistinguishable), but are
>somehow invalid?

Yes. BY DEFAULT they do NOT respect the binding of variables to
values.

>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.

And C++ respects the binding of variables to values (unless you write
buggy code). 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.

That is, the concept of a placeholder referenced potentially by more
than one variable only becomes an issue if you specifically ask for
it.

Roy Smith wrote:

> The wierd thing is that I don't think either one really matches what a
> mathematician means when he writes "=". In math, "=" is neither an
> assignment or a test: it's an assertion.

Right. In fact, when a mathematician really does mean rebinding, they
use an operator decidely unlike =, often :=, <-, <=, or some other
similar ASCIIzation. The equals sign in mathematics does not mean the
same thing it does in modern programming languages. It's just something
that one has to deal with early on or be forever annoyed.

It's arguable that the Pascal family has the most mathematics-like
operations for equality and assignment here, but really it's just a
semantic issue of knowing which operator means what. One can even get
used to things like % means string formatting if one really tries .

--
Erik Max Francis && && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Does the true light / Of love come in flashes
\__/ Sandra St. Victor