Fruits of X3J11 (was Re: quotes inside #if 0)

[Henry Spencer]

In article <14646 at bfmny0.UU.NET> tneff at bfmny0.UU.NET (Tom Neff) writes:
>Rather than rely on bureaucratic interpretation of a lengthy spec, why
>not publish a portable Standard C compiler, written in K&R-1 C, which
>exhibits the characteristics of a conforming compiler and is suitably
>commented with references to the spec?  ...
>It seems to me that questions of "what do you do if X follows Y under
>condition Z" would be a lot easier to deal with if the answer were
>"whatever Standard C does" ...

Unfortunately, what this amounts to is writing a new standard.  It will
be a much stricter one too, because there are a number of places in
ANSI C where the author(s) will have to choose one specific approach.
(For example, they will have to decide whether to use a tokenized or
string-based preprocessor, and the effects of this decision *will* be
visible.)  This is guaranteed to make it unpopular with implementors
who have taken different approaches, and their customers.  It won't get
anywhere near the level of acceptance that the current spec, warts and
all, can expect.

There is also the problem that you have to read the compiler to get
answers to your questions.  (Just experimenting with it won't do -- an
experiment answers a question only for a specific program, and doesn't
tell you how widely applicable the answer is.)  Compilers tend to be
a whole lot less readable than even ANSI standards.

There is much to be said for expressing standards in formal notations,
and much to be said for making formal notations executable, but C is
not a very good notation for the job, because it forces decisions on
too many low-level details that should be left open.  And any formal
notation has readability problems for anyone but the High Priests.
-- 
V7 /bin/mail source: 554 lines.|     Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry at zoo.toronto.edu