Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Sun, 13 Sep 2015 04:45 am, rurpy at yahoo.com wrote:

> On 09/12/2015 10:32 AM, Steven D'Aprano wrote:
>> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
>>[...]
>> Computer science and IT is *dominated* by a single usage for "pointer" --
>> it's an abstract memory address. The fundamental characteristics of
>> pointers are:
> 
> Just upthread, you claimed something was "universally agreed"

I did? "Universially agreed" doesn't sound like something I would say. Do
you have a link to where I said that?

I think you're confusing me with somebody else. Somebody who is not me.



[...]
>> Python, Java, Ruby, Lua, Javascript etc. have *no such concept* as
>> pointer. There are no values in these languages which correspond to the
>> standard definition of pointer:
> 
> They have not such concept because the developers and documentors choose
> not to describe that language that way. That does not mean one could not
> come up with a perfectly valid description that did include the concept
> of pointers.

I have little problem with you using "pointer" as a metaphor: "Python
variables are like pointers in these ways...". I do have a problem with you
insisting that they are pointers.

You can, if you choose, decide to change the meaning of the word "pointer".
After all, as a general English term, it just means a type of dog. No,
wait, that's the wrong meaning. It means anything which points in some
fashion, like a dog.

But as I said to Rurpy, if you're going to insist on using your own meanings
for words, the onus is on you to ensure that people aren't going to
misunderstand you. Sure, you could insist that `x = math.sin(1)` makes x a
string, and justify that piece of obnoxious linguistic trickery by saying
that x is a string of bits, but I think that we'd be justified in objecting
to that misuse of terminology.

Sure, you can insist that `x = math.sin(1)` makes x a pointer, but that too
is a misuse of terminology.

You can continue to call Python variables "pointers". After all, language is
a construct, and words have no meaning but that we give them, and there is
no law that says you are forbidden from using your own private meaning of
words. And when you do, I shall continue to object vehemently to your
wilful malapropism.


[...]
> It may not be appropriate way to describe Python for everybody but
> it is perfectly reasonable (and even preferable) for people with
> an understanding of "pointers" from some other language. And for
> those people who don't then one could argue they are a clean slate
> and using the word "pointer" won't hurt.

No, it is not reasonable. 

You want to insist that `x = 23` in Python code makes x a pointer. But that
Python snippet is analogous to to the following C and Pascal snippets:

# C
int x = 23;


{Pascal}
var x: integer;
begin 
  x := 23;
end;


Do you insist that they are pointers to? Then everything is a pointer, and
the word has no meaning. 

Regardless of which of the three languages we are talking about, the
assignment `x = 23` does not mean "bind some value to x which, when
dereferenced, gives the value 23". The value bound to x is 23, not some
indirect pointer to 23.

The *implementation* of how names and variables are bound may (or may not)
involve pointers, but that is outside of the language abstraction, whether
we are talking about Python, C or Pascal.

To call x a pointer to 23 breaks the language abstraction and confuses the
(optional) implementation for the language interface:

* CPython's implementation of namespaces may include a hash table, 
  where the table's values are pointers to objects in the heap;

* C's and Pascal's implementation of variables may include a 
  compile-time table of variable names mapped to memory addresses;

All three implementations may include a "thing-which-points" (Python name
bindings may involve C pointers to objects implemented as C structs; Pascal
and C variables may involve a compile-time table that points to the memory
address of the variable being accessed), but NONE of them justifies calling
x a pointer in ANY of those languages. 

If it helps you understand Python's programming model to discuss the
implementation, by all means do so. But be clear that you are talking about
*implementation* and not Python code.



-- 
Steven