Terminology: "reference" versus "pointer"

rurpy at yahoo.com rurpy at yahoo.com
Sat Sep 12 15:58:26 EDT 2015


On 09/12/2015 11:48 AM, Steven D'Aprano wrote:
> On Sun, 13 Sep 2015 02:17 am, rurpy at yahoo.com wrote:
> [...]
>> the model of Python I eventually 
>> developed is very much (I think, haven't read the whole thread) like
>> Random832's.  I think of boxes (objects) with slots containing "pointers"
>> that "point" to other boxes.  Even today when dealing with complex
>> Python data structures, I draw boxes and arrows to help me understand
>> them and think of the arrows as "pointers".
> 
> If you're going to abuse terminology, why don't you call the boxes "floats"
> since they "float around in memory",
> [...]

I was not proposing that, I was talking about the use of the term
"pointer".

> C is not the only, or even the first, language to have standardised on a
> meaning for pointer in computer science. Pascal had pointers long before C,
> and I'm sure Pascal wasn't the first either.

[I'm not sure about the "long before" part given they were nearly
contemporaneous.]

Right, and each of them uses the word (and others like "function", "call"
"arguments", etc) in their own specific way, which they define as part
of the description of the language. "function" in C is different than
"function" in Pascal which is different than "function" in Python.

That C (or Pascal) used the term first does not mean that it was
"standardized" by that use to have that precise definition forever after.

> "Pointer" is a standard primitive data type across dozens of languages: it's
> an abstract data type holding the memory address of a variable (either a
> named, statically allocated variable, or more often, an anonymous,
> dynamically allocated variable). As such, it requires that variables have a
> fixed address. If the variable can move, the pointer will no longer point
> to the variable.

See my comments on "fixed address" in another post.  Your definition of
"address" is too narrow.

> If you want to use "pointer" to refer to something else, the onus is on you
> to make it clear that you're using it in a non-standard way.

Of course. Nobody should ever say (a least formally) just "pointer" and
expect the entire (assumed diverse) audience to have a common single 
understanding of what is meant. But that applies to most terminology 
like "reference" as well.  It is why language documentation has things 
like definitions and glossaries.

> Some day, most programmers will be using nothing by dynamic languages which
> lack pointers-the-data-type,

I don't think there is any direct relationship between pointers and
dynamic languages. Go is not a dynamic language yet it does not not
allow unrestrained pointer use a'la C.

My impression is that unmanaged pointers (in the C sense) are recognized
these days as dangerous and that nearly all new languages including static
ones manage "pointers" (perhaps under a different name) to prevent the
problems that occur with C.

> and the term will lose its baggage and can be
> safely used as a generic English term for "a thing which points". The tiny
> minority of systems programmers writing device drivers and kernel code in
> Rust (C having been long-since delegated to the wastebin of history -- well
> that's my fantasy and I'm sticking to it)

That's fine, so we are talking about the far distant future, maybe
year 3000 or so. :-)

> will learn that, outside of their
> own niche, "pointer" does not have the technical meaning that they are used
> to, and everyone else will be as blissfully unaware of said technical
> meaning as the average programmer today is of continuations and futures.
> 
> But this is not that day.

I think you underestimate the ability of human beings (even programmers)
to interpret words in a context dependent way.
 
The question is whether what "pointer" means in languages that use the
word is *so* different than its meaning in the Python sense, that using
it for Python is more misleading than helpful. You think so, perhaps
because you focus on the unmanaged and memory-address aspects of its use.
I consider those as non-determining characteristics of a thing that points
to something and instead consider its pointingness to be its defining
characteristic, in those languages and in Python, and thus find it 
perfectly descriptive for Python.



More information about the Python-list mailing list