🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #1896

Re: Answers, Chapter 1: TeX

#1896
From: Jim Giles
Date: Fri, 02 Nov 1990 21:50
82 lines
4428 bytes
From article <27094@megaron.cs.arizona.edu>, by gudeman@cs.arizona.edu (David Gudeman):
> [...]
> Well then you are really making three distinct arguments and
> confusing your readers by merging them into one, aided and abetted
> by a specialized terminology that the net public in general do not
> share.  Your arguments seem to be (I'll assume everyone agrees that
> arrays are multi-dimensional):

I'm glad you assume that arrays can be multidimensional.  Before the
advent of C, this was accepted by nearly everyone as one of the possible
properties of arrays.  This is not (or, at least, _should_ not be)
"specialized terminology that the net public in general do not share."

> [...]
> (1) Arrays should be bounds checked.

At least as an option, yes.  Further, the compiler should be allowed
(and able) to make use of its knowledge of the bounds to generate more
efficient code (especially for statically allocated arrays where the
bounds are fixed).  Again, before C, this was a universal assumption.
Are you telling me that this property of arrays is one that net readers
are not aware of?

> [...]
> (2) Aliasing of data structures should not be allowed unless made
> explicit by declarations.

That is the only new point that I have introduced.  And, as such,
it has been the one that I've taken most pains to point out.
Nevertheless, this has _always_ been true of arrays in most
programming languages (other than C and its relatives).  So, with
respect to _arrays_, this should still be a fairly widely
acknowledged property - even if not universal because of C.

>  [...]
> (3) Pointers should not have a dereferencing operation.

This is only a minor point which makes the syntax of using recursive
data structures more legible.  In fact, the only objections I have
to pointers a`la Pascal are the syntax and the lack of a way to
inform the compiler when two pointers of the same type are _not_
aliased.  So, aside from those two changes, my "aliased" attribute
is identical to Pascal style pointers.  This has little to do with
the `C style pointer vs. array' debate.

> [...]                                          You haven't eliminated
> pointers, you have just changed them to something similar.

When comparing to Pascal sytle pointers, this is indeed what I have
done.  It is also what I've said all along that I've done.  That is
what I mean when I say that something is semantically equivalent:
it has the same meaning with a possibly different syntax.

> [...]            There is no reason why pointers in some language
> could not be defined to be bounded and unaliased.  If pointers were
> defined that way, then pointers would have property X. [...]

In which case, why call them pointers?  Surely to call such things
"pointers" would be to use "specialized terminology that the net
public in general do not share." In fact, the terminology that the
net public share is C and/or possibly Fortran and Pascal.  Most
other languages seem to be relegated to the category of esoterica.
Certainly, nothing outside those bounds can be regarded as shared.
So, in a net discussion, pointers are those things in C or perhaps
limited to those things in Pascal.

> [...]
> To make the situation even more bemusing, your version of pointers
> without dereferencing constitutes a direct counter-example to what you
> claim is impossible for pointers.

On the contrary.  If you'll look more carefully at my past articles on
this subject, you will find that the objects that I call "aliased"
variables have all the bad properties that I ascribe to pointers.
They are more strictly bounded, so that the damage is limited to those
operations involving variables in the same "aliased" declaration.
But, the damage is there.  This more strict limitation on aliasing is
one of the two differences between my proposal an Pascal pointers:
this is the only semantic difference.  Again, this has little
relevance to the `C-pointer vs. arrays' debate.

J. Giles
Technical Details
Message-ID: <4837@lanl.gov>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!agate!shelby!rutgers!cmcl2!lanl!jlg
References: <27094@megaron.cs.arizona.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!agate!shelby!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Answers, Chapter 1: TeX
Message-ID: <4837@lanl.gov>
Date: 2 Nov 90 21:50:36 GMT
References: <27094@megaron.cs.arizona.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 82