[COFF] Commonality of 60s-80s Print Standards

[Paul Winalski]

On 8/17/23, segaloco via COFF <coff at tuhs.org> wrote:
>
> To summarize, why do print copies of primary standards from the elden days
> of computing seem like cryptids while one can flatten themselves into a
> pancake under the mountains upon mountains of derivative materials out
> there?  Why is filtered material infinitely more common than the literal
> rule of law governing the languages?

I worked as a software engineer in the 1980s and '90s in Digital
Equipment Corporation's unit that developed tools for programmers,
including the compilers.  I don't recall the policies and procedures
of the various ANSI computer language standards committees regarding
publication of the standards.

I think the reason that there aren't many extant copies of them out
there is that not many people actually cared what the standard said.
What was important was the details of the particular implementation of
the language that you as a programmer had to use.  Even within DEC's
compiler group, there were only a couple of copies of the ANSI
standard document for any particular language.  A typical compiler
group has only one engineer tasked with standard interpretation and
compliance.  The rest of the compiler developers work from the
specification for the upcoming release.

>  For instance the closest thing to the
> legitimate ANSI C standard, a world-changing document, that I can find is
> the "annotated" version, which thankfully is the full text but blown up to
> twice the thickness just to include commentary.  My bookshelf is starting to
> run out of room to accommodate noise like that when there are nice succint
> "the final answer" documents that take up much less space but seem to
> virtually not exist...

For a compiler developer, that isn't "noise".  Official specifications
for computer languages often contain--despite the best efforts of the
committee members to prevent them--errors, inconsistencies, vague
language, and outright contradictions.  It's the compiler
developers--especially those working on incoming bug reports--who have
to deal with problems in the standard.  It helps to have an idea of
what the committee members' intentions were, and what their rationale
was, for particular verbiage in the standard.  I know DEC's
representatives to the C standard committee, and in the case of the C
and Fortran standards the extra verbiage was completely intentional.

In case law, the Judge's decision in a trial usually is a page long,
sometimes only a sentence or two.  But there may be 80 pages of legal
reasoning explaining just why the judge came to that conclusion.
Compiler developers end up being language lawyers.  When a problem
comes up regarding a language feature, they want to know the
committee's intentions and rationale for why the standard says what it
does say (or appears to say).

-Paul W.