🚀 go-pugleaf

(given the number of articles I'm writting, I must have a lot of spare
time these days...)
In article  <14330@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>Here, it is the _purpose_ of the code to
>return a reference to undefined values (undefined until allocation is
>complete anyway).

There is a difference between an undefined _operation_ on a pointer
and pointing to an undefined _value_.  I'm sorry Jim, but it should be
obvious that the 3-tuple scheme does not prevent malloc() from
working, and it really looks like you are resorting to desperate
rhetorical ploys in an attempt to support your position.

>> Are you suggesting that it would be an _advantage_ if pointers could
>> be used like this?
>> int foo()
>> { int *p, i,j,k,l,m,n;
>>   for (p = &i; p <= &n; p++) do_something(p);
>> }
>No.  I would not recommend such a thing.  Nor do I suggest using pointers
>as a poor cousin of an array.  I want pointers to behave as addresses
>within the linear address space presented to the user by the system.

And the 3-tuple system does exactly that.  It only prevents the user
from doing things that have no defined meaning.  As to "poor cousins",
I wish you would stop pretending that there is something objective
about your personal distaste for the way pointers are used.  There are
a lot of people who think that

  for (p = A; p < A + A_SIZE; p++) foo(*p);

is more elegant than

  for (i = 0; i < A_SIZE; i++) foo(A[i]);

it is just a matter of taste.  You sound like an art critic who thinks
that his personal tastes are universal constants, and that others who
don't like the same things are "wrong".
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman