🚀 go-pugleaf

In article <65409@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>[...]						  But, addresses
>aren't particularly important to me.  I almost never need to know
>or manipulate them in any way.  So, why do I need a data type who's
>values are addresses?

    (a) Because, although *you* may not, *others* may, or may think
	they do, or may simply prefer to think of things that way.

    (b) Because, although I may never want to manipulate addresses
	in the bit-twiddling way you seem to be suggesting, I *do*
	quite often want fingers.  If I search a data structure for
	elements with some property (the "largest" node, or the pair
	that are furthest apart, or whatever) it is reasonable to
	keep fingers on the results.  You can certainly disguise the
	pointer-ness of what I am doing, but I don't see why you should
	have to, or indeed want to.

> [...]							  We are no longer
>in the days when anyone _cared_ about the absolute addresses of anything.

	(*Some* people still do, as PCG points out elsewhere.)

>Why have a data type which purports to represent them?

	In most HLLs, no such representation is purported.  A pointer is
simply a way in which one object can make reference to another, which
sounds like a pretty useful abstraction to me.

In article <65662@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>[...]	     The rank and extent of an array is fixed for the lifetime
>of the array [...]

	This will be news to Algol programmers.

> This means that the concatenate operator is [...] of doubtful use
> for arrays [...].

	MODE STRING = [1: 0 FLEX] CHAR;
	STRING s := "tomorrow";
	s +:= 2 * (" and " + s) + " creeps in ..."
	C apologies to Shakespeare! C

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