🚀 go-pugleaf

In article <PCG.90Nov3185931@athene.cs.aber.ac.uk> pcg@cs.aber.ac.uk
(Piercarlo Grandi) writes:

>Note that many links or nodes may have the same info, but a specific
>link or node will be uniquely identified by context; if it cannot, e.g.
>a two node graph like this:
>
>		"B"
>	   .-------------.
>	  "A"		"A"
>	   \_____________/
>		"B"
>
>then the graph is inherently ambiguous.

	Well, to use your notation of "top", etc., I would describe
such a graph by code somewhat like

	NODE top = ("B", (left, right)),
	     bottom = ("B", (left, right)),
	     left = ("A", (top, bottom)),
	     right = ("A", (top, bottom));

in which both the disambiguation and the duality are clear.  Of course,
this is somewhat like your database.  But "top" itself does not include
a description of its own location -- that is a matter for the compiler.

>You got it the other way round: if pointers make a difference, this can
>only mean that part of an object's content are implicit in its in-memory
>location, not viceversa (what actually happens is that location includes
>a bit of content).

	No:  it means that location can be used to disambiguate objects
without the need for programmer invention.

>anw> Furthermore, if I am denied access to the algebra of locations,
>anw> then some useful ideas like anonymous objects, and like remembering
>anw> locations, become inexpressible.
>
>They are most definitely not useful at the application level,

	They most definitely are!  When I give people directions to my
house, I include things like:  "Take the third on the right, ...", "If
you get to the Hemlock Stone, you've gone too far, you should ...", and
"If you get lost, ask for Priory Island, and try again from there".  I
don't want to name all the junctions, so the first two on the right are
anonymous;  but some key locations need to be remembered.  This is all
quite similar to the usage in "pic", Brian Kernighan's graphics language:

	arrow dashed from last circle.left to last box
	line up from top of Here
	arc from start of 2nd line to 2/3 of the way between A and B

and so on.

>You have a claim that pointers are necessary, if I understand correctly.

	That's an exaggeration.  I managed without pointers perfectly
well until 1972, and wrote [IMHO] much good code by the standards of
those days.  But I (and almost everyone else) also managed without
characters [except as "caption"s], structures, enumerations, sets,
not to mention files, editors, discs, terminals, ....  All of these
things have greatly increased my productivity, and I wouldn't want
to turn back the clock.

>What you want to do is to represent entities, not be concerned about how
>the relevant encoding is done.

	Just so, which is exactly why I am happy for my entities to
include pointers to other entities, and to let the compiler worry
about how it is actually done in machine code.

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