🚀 go-pugleaf

On 10 Oct 90 10:15:27 GMT, anw@maths.nott.ac.uk (Dr A. N. Walker) said:

anw> Like everyone else over here, I'm missing the (initial) context, but I
anw> found this interesting:

Yes, good spotting!

anw> In article <1990Oct8.135551.21639@arnor.uucp>
anw> lowry@lusitania.watson.ibm.com (Andy Lowry) writes:

lowry> I personally have written a great deal of code in Hermes and have
lowry> found the lack of pointers to be no hindrance. [...]

lowry> Of course, our compiler and run-time system make heavy use of
lowry> pointers and shared data for reasons of efficiency, but this is
lowry> completely hidden from the Hermes programmer.

anw> In other words, here is a construct which is incredibly useful for
anw> writing compilers and other programs, but which the ordinary
anw> programmer is unable to use.

Good point! And precisely my point too: pointers are nearly
indispensable to write *implementations*, because our machines use them.
But the other guy also has a point: if your implementation is
efficiently written using pointers, your application can abstract away
from them.

anw> I don't think languages should hide useful abstractions from
anw> programmers; they should hide annoying concretions instead.

But pointers are a useful concretion, not an abstraction...

anw> I don't really want to know the machine address of a variable,
anw> or how to represent a conditional jump in machine code, or which
anw> registers need to be saved over a procedure call.

If you are doing fundamental *implementation* (OS, runtime library,
profiler, debugger, compiler, ...) work, you want of course to deal
explicitly with such things. It all depends on where you put your
virtual machine boundary -- if your virtual machine is a C virtual
machine, or an Ingres virtual machine, or a SPARC virtual machine,
etc...

anw> But I do want to be able to express within my language all the
anw> abstractions that naturally arise in modelling my problem.  These
anw> may well include pointers ["keep a finger on that variable"], even
anw> when there are no `data structures' around.

Again: you never need pointers to model your *application*. Pointers
actually cloud abstractions because they introduce an extra layer of
manipulation (pointer values) that does not exist at the application
level (that is only expressed in data values). If you have very simple
relationships in your application, pointers are just one of the ways of
*implementing* them, and one of the least interesting and nastier.

If the machines we are programming had identification-by-contents for
objects we would not need pointers at the implementation level; but they
do not, so we must use pointers, identification-by-tagging, as a poor
substitute on which to build the more useful and application oriented
abstractions for relationships, using usually far more sophisticated
mechanisms than pointers.

I strongly believe that a lot of computer science, I think actually
almost all of it (if you accept the idea that numeric analysis is not
strictly CS :->), is about trying to simulate identification-by-contents
using identification-by-tagging.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk