🚀 go-pugleaf

In article <1990Oct15.204343.2907@arnor.uucp> lowry@lusitania.watson.ibm.com
(Andy Lowry) writes:
>The point I meant to make is that indirect addressing is a fact of
>life in most of today's computer architectures.  Therefore, pointers
>will certainly be found in efficient implementations of many programs.
>This does not mean that the pointers need to show through in the
>languages in which the programs are written.

	True.  But no-one has yet given a convincing (to me!) reason
why pointers should *not* show through.

>					       Many computers also have
>segment registers, process status registers, data caches, and other
>such features, but I'm not ordinarily aware of them when I write
>programs.

	Umm.  Not directly, perhaps;  after all, many such features are
transparent even at the assembler level.  However, you may soon have a
poor data locality, for example, brought indirectly to your attention
when the data cache ceases to be effective -- I have seen programs very
suddenly run over 100 times more slowly when an array size crept over
some limit.  [Admittedly, this was in 1965;  but I expect Jim Giles sees
it happen even today when vectorisation fails.]

>	    When we implemented the Hermes run-time system, we did, in
>fact, make heavy use of pointers.  This is because we wrote the system
>in C, where pointers are indispensible.  We believe that we have
>designed Hermes in such a way that pointers are not indispensible.

	Presumably an acid test will come when the system is written
in Hermes and becomes self-supporting.

>I expect you actually think of them as a collection of nodes and arcs.

	["you" is me, and "them" is trees and graphs]

>The Hermes programmer could represent a graph precisely in the
>standard conceptual manner--as a collection of nodes and a collection
>of arcs, where each arc is a record containing two node id's.

	Indeed.  But the first actual implementation of graphs that
I clapped my eyes on started out something very like

	MODE GRAPH = STRUCT (VERTICES v, EDGES e),
	     EDGE = STRUCT (REF VERTEX a, b),
	     VERTEX = ...etc...

which seems not so far away.  The distinction between "each arc is a
record containing two node id's" and "each arc is a record containing
two pointers to nodes" seems rather slight, and amounts to "who provides
the node ids?".

> [recompilation]				 is much cheaper and
>less error-prone than re-engineering a C program because reverse
>traversals are suddenly needed in a structure that has only forward
>pointers.

	On the other hand, if reverse traversals are suddenly needed
in a program that was designed on the assumption that they weren't
necessary, re-engineering might be thought highly desirable.

	There are also some problems with compilers that change
algorithms behind the programmer's back, depending on some complicated
analysis.  Suppose my program has a bug that is benign in some
implementations, but not in others.  Lo and behold, all my test programs
work, the production run fails, and as soon as I try to isolate the bug,
it goes away.  (Yes, I know we all have bugs like that sometimes!)

	[Nothing in this should be read as implying that I'm agin the
Hermes project.  What I've heard about it sounds interesting, and
systems that raise levels of abstraction should be encouraged.  I
just don't see pointers (in particular) as undesirable aliens that
*should* be abstracted away.  They are useful citizens, just like
integers and procedures, to be harnessed with care.]

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk