Re: What other languages use the same data model as Python?

Newsgroups	comp.lang.python
From	Albert van der Horst <albert@spenarnc.xs4all.nl>
Subject	Re: What other languages use the same data model as Python?
Date	2011-05-20 21:17 +0000
Message-ID	<llij5q.4cb@spenarnc.xs4all.nl> (permalink)
Organization	Dutch Forth Workshop
References	<4dbd1dbf$0$29991$c3e8da3$5496439d@news.astraweb.com> <92f70aF9pqU1@mid.individual.net> <4dc7fa2f$0$29991$c3e8da3$5496439d@news.astraweb.com>

In article <4dc7fa2f$0$29991$c3e8da3$5496439d@news.astraweb.com>,
Steven D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>On Mon, 09 May 2011 12:52:27 +1200, Gregory Ewing wrote:
>
>> Steven D'Aprano wrote:
>>
>>> 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.

<SNIP>

>
>--
>Steven

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Thread