Path: utzoo!attcan!uunet!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Answers, Chapter 2: to point or not to point
Message-ID: <65610@lanl.gov>
Date: 22 Oct 90 22:50:54 GMT
References: <26692@megaron.cs.arizona.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 52

From article <26692@megaron.cs.arizona.edu>, by gudeman@cs.arizona.edu (David Gudeman):
> [...]
> You should qualify this as "the advantage of the high-level structures
> I have been discussing".  High-level structures in general are no
> easier to implement efficiently --and usually a good deal harder--
> than low-level structures.  For example run-time type checking,
> generalized lookup tables, pattern matching, unification, term
> rewriting, and automatic storage management are all much higher level
> than the features you have been discussing.

Fair enough.  Too be sure, on of my criteria for selecting features
is the knowledge of an efficient implementation that has been around
long enough to be solidly reliable.  All the features I've mentioned
fit this criterion - or, like deliberate aliasing, are sometimes
necessary even if inefficient.  However, the less efficient modes
are deliberately _not_ the default ones.

As for the higher-level features you mentioned: when the technology
matures, I'm sure that a number of them will become efficient and
reliable.  When that happens, I'm sure that they too will generally
be more efficiently implemented automatically by the compiler than
by all but the most adept programmers.  And even those _most_ adept
will still prefer to use the high-level features except when absolute
efficiency is the _only_ criterion for the program.  Other than that
the ease of maintenance, legibility, or the speed at which the code
is available and fully debugged will almost certainly be the overriding
factors.

> In fact I wouldn't even use the term "high-level" to qualify most of
> the things you have discussed.  I know it is non-standard, but the
> terminology for classifying data structures has not kept up with rest
> of the field.  I'd call most of your suggestions medium-level.

Again, fair enough.  The seven data structures I posted are copied
almost exactly from C.A.R. Hoare's chapter in "Structured Programming",
which was published in 1972.  Again: a basic criterion was reliability.
Old features have a longer track record and are more likely to meet
the criterion.  This, by the way, was the criterion Hoare applied
to the selection of features as well - 18 years ago!

The 'new' features that I've mentioned aren't really new either.  The
'aliased' attribute, for example, is just _exactly_ the same semantic
object as Pascal pointers - the difference is mainly syntactic (plus
the fact that aliasing is quite a lot more constrained than Pascal
pointers allow - aliasing is an attribute of specific collections of
variables and not a property of the data type).

However, nomenclature aside, these features are clearly much higher
level than pointers: the lowest level data structuring tool above the
bit.

J. Giles