🚀 go-pugleaf

In article <Bz7tKM.KDF@grex.ann-arbor.mi.us>, mcdaniel@grex.ann-arbor.mi.us (Tim McDaniel) writes:
> What is a "normative addendum"?

ISO allows for two different types of addenda (appendices): normative
and non-normative.  A normative addendum is an actual part of the
standard, a non-normative addendum is explanatory comments which are not
part of the official standard.  Addenda can be part of the standard from
the very beginning or can be added after the fact to modify or clarify
an existing standard.

> What insane asylum added digraphs to the existing trigraph mess, and
> also said that the "difficult" characters have to exist anyway?  What's
> the point of trigraphs and digraphs then?
> 
> What fool made these identifiers ("or", "ne", ...) reserved?  "If you
> want PL/I ..." and all that.  (Designing a language from scratch, I
> would have used "and", "or", et cetera.  But C didn't, but now we have
> both.)

This is a bit of a contentious issue, so I will try to keep my personal
opinions in check until after I relate the facts.

First, a bit of history.  Back when X3J11 was working on the ANSI C
Standard, one of the deficiencies of C that the committee was asked to
address was the problem that C used most of the ASCII character set but
many machines do not have all of those characters available.  In
particular, when ASCII (which is a US standard [X3.4]) was
internationalized into ISO 646, a number of characters (0x40, 0x5b -
0x53, 0x60, and 0x7b-7e) were  designated as "National or
application-oriented graphic characters".  This means that any nation
can have a national standard that specifies the meaning of these
characters as well as individual applications can define them as they
wish.  Also, character 0x23 is allowed to be defined as either the
(British) pound sign or the number sign, and 0x24 is allowed to be
defined as either the (US) dollar sign or a generic currency symbol. 
In the USA, the ASCII standard defines these characters as commercial
at (@), left square bracket ([), reverse slant (\), right square
bracket (]), circumflex accent (^), grave accent (`), left curly brace
({), vertical line (|), right curly bracket (}), tilde (~), number sign
(#), and dollar sign ($).  Other nations have similar national
standards that define these characters quite differently.

X3J11 felt that it was important, if the C Standard was to be an
international standard, to be able to write a C program using only
those characters that were guaranteed to exist -- those characters
defined in ISO 646 that are NOT redefinable.  We also felt that it was
important to be able to convert to and from that notation very easily;
in particular, it should be possible to do the conversion without
having to parse the C program so that a simple text substitution (e.g.
a sed script) is sufficient to convert back and forth.  We tried to
come up with digraphs, but there aren't enough to meet these criteria. 
Thus, trigraphs.  Our thoughts at the time were that trigraphs would be
most useful for moving programs from one environment to another; we
assumed that most systems had *some* way to represent these characters
that would be used locally, although trigraphs could be used there as
well.  And, of course, a user is always free to create a header with
macros for the difficult characters and use those instead (although
that won't work inside character or string literals).  X3J11 recognized
that trigraphs were a bad solution to a vanishing problem, but it *is*
a problem and there didn't seem to be any better solutions.

At the same time that X3J11 was finishing up the ANSI C Standard, ISO
began work on an International Standard for C as Working Group 14 under
Subcommittee 22.  The Danish delegation remarked that they did not, in
fact, have a way of representing those characters on their terminals,
trigraphs were ugly, and they would like some better method.  What they
proposed was a collection of digraphs and keywords.  X3J11 examined
their proposals and pointed out a number of objections, both technical
and aesthetic, pointed out that trigraphs were a solution to the
problem, and declined to make any changes to the (draft) ANSI Standard.
The Danes then revised their proposal and the cycle repeated a number
of times.  Eventually the ANSI C Standard was approved as it appears
today and the ISO C Standard was also approved with identical technical
content for expediency although a number of delegations had issues that
they wanted to have addressed via normative addenda later.

Now, it's later.  Denmark has brought a number of proposals to WG14,
asking for approval as a normative addendum.  X3J11 in it's role as
Technical Advisory Group to the US delegation has continued to advise
against adopting any of the proposals both because of technical
conflicts and because we do not believe that they add any significant
value to the C language.  In the meantime, however, both ANSI and ISO
have also started projects to standardize C++, the Danes made a similar
proposal to those committees, and it has been accepted.  SC22, the
parent committee of both the C and C++ working groups, has resolved that
the Danes' concern be addressed and further charged both working groups
with avoiding gratuitous incompatibilities between C and C++.  At the
meeting last week, X3J11 finally gave up and recommended that the US
vote to accept the current Danish proposal as a proposed normative
addendum to the ANSI/ISO standard.  The substance of that proposal
should be fairly obvious from Doug's posted implementation.

If you think this is a crock, then what we need to do is to get it shot
down by a wide variety of countries at the ISO SC22 level rather than
having the big bad USA picking on poor little Denmark which is how some
people have viewed X3J11's objections.  For additional information, I
suggest you contact the chair of WG14, P. J. Plauger (pjp@plauger.com).
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
Let's just sit here a moment... and savor the impending terror. -- Calvin