What other languages use the same data model as Python?

[Hans Georg Schaathun]

Language is for communication. If we're not using the same meanings
: for words, we will have problems.

So if you adopt the word class to mean a type (or composite type),
as in python, what word would you use for a class of types (as in
haskell or ada)?

I think there are too many meanings and too few words ...

That's why some languages support overloading.

I am afraid we just need to cope with it, overloading I mean.

 

[Chris Angelico]

 Language is for communication. If we're not using the same meanings
:  for words, we will have problems.

So if you adopt the word class to mean a type (or composite type),
as in python, what word would you use for a class of types (as in
haskell or ada)?

I think there are too many meanings and too few words ...

That's why some languages support overloading.

Of course. Nobody ever said that one name had to point to one value... oh wait.

Yes, Virginia, there is overloading.

Chris Angelico

 

[Terry Reedy]

Actually, you're right. What I've presented is a paper-and-pencil
implementation of the Python data model. Together with a set of
rules for manipulating the diagram under the direction of Python
code, you have a complete implementation of Python that you can
execute in your head.

I think that it would be both fun and useful to have an animated
graphical tutorial that used and box and arrow model. Names should be in
ovals (instead of the little boxes used here due to text limitations) to
differentiate them from objects. Immutable objects could have solid
boundaries and mutables a broken line boundary. Collection objects would
have dotted lines to separate slots. Ovals could also use different
lines for builtins, globals, and locals.

And you NEED such an implementation in order to reason correctly
about Python programs under all circumstances.

I find it very difficult to imagine *any* implementation of
Python, computer-based or otherwise, that doesn't have something
equivalent to references. Whether you call them that, or pointers,
or arrows, or object bindings, or something else, the concept
needs to be there in some form.

Since namespaces link names in a namespace with objects not in the
namespace, any practical implementation needs a third entity to link or
associated each name with an object. This is pretty much needed to
explain multiple links without objects being in multiple locations. It
is also needed to explain how an object can link to itself.

 

[Gregory Ewing]

There has to be a way to get from some mythical "home" location (which
we know in Python as locals()+globals()+current expression - the
"current namespace") to your object. That might involve several names,
or none at all, but if there's no such path, the object is
unreferenced and must be disposed of.

Yes, that's what I mean by "bound to some anonymous thing".
Somewhere in the implementation there must be one or more
"root" references, but they don't necessarily have any names
that you can refer to from Python.

When I say "not bound to any name", I just mean that it's
okay to leave some bindings out of your diagram if they're
not pertinent to what you're trying to illustrate. For
example, you can draw a box representing a string object
and trust that something will keep it alive long enough
for you to draw an arrow to it from the name you're
assigning it to.

 

[Albert van der Horst]

I think "manipulate" here means things like pointer arithmetic, which
are perfectly normal and common in C and assembly, but not in
languages where they're references.

Adding an integer to a reference to an array element could have been
perfectly well-defined in Algol:
ref real operator+(ref real, int)
That is called overloading of the plus operator not "pointer arithmetic".
It is a misconception that these manipulation are dirty or ill-defined
or unsafe.

A similar extension would be possible in Python.
Allusion to assembler where one adds a number to a register
and can't tell whether the register contains an address or data
are misleading.

[This is not to say that I think it is advisable].

Chris Angelico

Groetjes Albert.

 

[Albert van der Horst]

Since you haven't explained what you think is happening, I can only
guess.

Let me save you from guessing. I'm thinking of a piece of paper with a
little box on it and the name 'a' written beside it. There is an arrow
from that box to a bigger box.

+-------------+
+---+ | |
a | --+---------------->| |
+---+ | |
+-------------+

There is another little box labelled 'b'. After executing 'a = b', both
little boxes have arrows pointing to the same big box. [...]
In this model, a "reference" is an arrow. Manipulating references
consists of rubbing out the arrows and redrawing them differently.

All very good, but that's not what takes place at the level of Python
code. It's all implementation. I think Hans Georg Schaathun made a good
objection to the idea that "Python has references":

In Pascal a pointer is a distinct data type, and you can
have variables of a given type or of type pointer to that
given type. That makes the pointer a concrete concept
defined by the language.

The same can't be said of "references" in Python. It's not part of Python
the language, although it might be part of Python's implementation.

Also
in this model, a "variable" is a little box. It's *not* the same thing
as a name; a name is a label for a variable, not the variable itself.

That's essentially the same model used when dealing with pointers. I've
used it myself, programming in Pascal. The "little box" named a or b is
the pointer variable, and the "big box" is the data that the pointer
points to.

It's not an awful model for Python: a name binding a = obj is equivalent
to sticking a reference (a pointer?) in box a that points to obj.
Certainly there are advantages to it.

But one problem is, the model is ambiguous with b = a. You've drawn
little boxes a and b both pointing to the big box (which I deleted for
brevity). But surely, if a = 1234 creates a reference from a to the big
box 1234, then b = a should create a reference from b to the box a?

There are cleaner languages. Algol 68 , Forth.
This is Forth.

VARIABLE A
VARIABLE B
1234 ( anonymous "object" created by the language ) A !
A @ B ! ( Copy the content, equivalent of B=A).

Algol 68
B:=A
compiler : THINK ! THINK !
A is a "ref int" so it can't be stored into b which is a "ref int"
which is the name of a place where an int can be stored (not where
a ref int could be stored.)
Solution: Algol dereferences A into an int, by getting its content.
But it is a rule, very explicitly explained in the language definition.
(If you are that clean you can handle "ref ref int q" where q is the name
of a place where a "ref int" can be stored.)
"real a" is in fact an abbreviation of "ref real a=loc real"
meaning "a" is a reference to a local real, that is anonymous.
The = means that the connection between a and that real is an identity,
i.e. the connection can't be broken. (Forget about C++,
"casting away const", yuck! )

In Forth and in Algol 68 storing a constant into a variable is
very different from copying the content of a variable to some
other variable.


Groetjes Albert