Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Answers, Chapter 2: to point or not to point
Message-ID: <66254@lanl.gov>
Date: 19 Oct 90 21:17:55 GMT
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 84

> [... again, even number of '>' is me, odd number is Dan Bernstein ...]
>
>> You're the one who insists that users be forced to explicitly monkey
>> with the implementation level of data structures.
>
> QUESTION 4: Has it gotten through your head that nobody's forcing you to
> abandon your high-level structures just because pointers exist? See
> question 5.

Well, you say that here.  But you say in your next article:

> Jim, nothing in Nemesis that you've described to me requires any
> extensions to implement in C; [...]

Well?  Which is it?  Am I to be forced through a 'pointers only'
intermediate or not?  The modifications I request are much less useful
if the code generator part of the compiler cannot directly access and
make use of all the semantic constraints appropriate to each data
object.  The advantage of high-level structures is two-fold: 1) it's
easier for the user to write, read, and maintain; 2) it's possible for
the compiler to make use of the semantic properties of these higher
level structures to generate better code.  You want to deprive me of
that second advantage.

> [... your other article follows with ...]
> [...]                       The programmer can get all the greatness and
> glory of the Giles Gaggle, with whatever typechecking and constraints
> you want, with at most a C++-like preprocessor. Agreed?

To be sure.  And, you _could_ remove all the control flow constructs
from C except a conditional GOTO and force all users of higher-level
control to pass through a preprocessor.  Conditional GOTOs can
simulate _all_ the "Gaggle" of control constructs that Structured
programming fanatics demand.  However, for efficiency the compiler
would have to be told, or have to rediscover, all the useful semantic
properties of the missing control constructs (like proper nesting and
so forth).  Automatic rediscovery of such properties may be completely
intractable.

Converting data structures to a 'pointers only' form is the same
kind of thing.  But it's a _lot_ worse in practice.  The lost
semantic properties are more numerous, more difficult to recover
(even with hints from directives) and have a more severe impact
on the quality of code generated than forced switching to GOTOs
would have.

I don't ask you to preprocess all control constructs into GOTOs, why
do you insist that I must preprocess all data structures into pointers?

You also have the following self contradiction:

> [... requote from above ...]
> Jim, nothing in Nemesis that you've described to me requires any
> extensions to implement in C; [...]

> [... from later in same article ...]
> For the compiler to take advantage of un-aliased variables, it either
> has to compile several copies of the code with different aliasing
> restrictions, or let the programmer talk about aliasing somehow. Convex
> lets you selectively specify pointer arguments as unaliased, for
> example. Q has an assertion to express the lack of aliasing. I admit
> that C as is, while powerful enough to support the Giles Gaggle, may not
> be perfectly efficient without some extensions. This is an area where
> language design has to advance.

Ok, which is it?  Either C requires no extensions or C does.  The
better efficiency of the constructs I've recommended are an inherent
_part_ of their purpose.  In order to provide this, C _must_ be
extended.  Since you agree that this is an area where language design
has to advance, you must accept the fact that including the structures
I recommend (directly in the language - NOT from a preprocessor) is
a way to accomplish just such an advance.

> [... this is one of Dan's statements that I've deliberately lifted   ...]
> [... out of context - it is false no matter where in this discussion ...]
> {... it appears ...]
>
> No; I merely see that this is not a human factor issue.

*ALL* language design issues are human factor issues.

End of chapter 2.

J. Giles