Multilevel standards

[Paul Schauble]

Reply to Hokey at GANG.UUCP

I appreciate the comments.  I wish I knew more about ANSI X11.1, because
I think I don't quite understand the idea behing "Standard Optional
Language Extensions".  How are these different from the COBOL
Multi-Level modules?

I agree that multi-level standards can be undesirable.  But there is a
real problem here.  "Standard" Pascal describes a mimimum language.  So
minimum that it is not usable.  I probably shouldn't claim that there
are no production quality standard Pascal implementations, but I don't
know of one and have never used one.  Because the standard is so
mimimal, every implementation extends the language to make it usable.
Because there is no standard for these extensions, they are all
different.  As a result, programs are not portable and the standard is
relatively useless.  Can we avoid this trap with C??

The other piece of this problem is in K&R itself.  Look at the page
opposite the CONTENTS page, where is says "Copyright 1978 by Bell...".
This book is almost seven years old!!  Has the language changed in the
meantime?  Certainly.  Not being a Unix person, can I find out how?
Where is the widely distributed and readliy available book that
describes the current language??  Ladies and Gentlemen of the standards
committee, I suggest that you should be writing that document.nn

Consider this:  during the three working days of this past week I tried
to move two C programs from Unix (vintage unknown) to an IBMPC using a
recent version of Computer Innovation C86.  Both failed, one because the
programmer assumed that structure element names were tied to the
structure rather than global and the other because it TYPEDEF'ed a
structure and then assumed it could be returned by a function.

Both of these features exist on current (for some values of current)
Unix compilers.  Which ones?  What other features are out there that are
going to bite me next week or the week after?

I look to a language standard to help solve these problems.  What help
is a standard that simply declares all of these compiler to be standard?

And that is the problem I see facing the standard committee.  If you
formalize K&R, perhaps with some minor updates, you will freeze a
snapshot of the language that is already badly out of date.  This will
be useless to a significant part of the language users.  If you make
more than trivial updates, you will omit a lot of current compilers and
cause political problems.

I see the source of the problem being that there really are two families
of compilers in this world:  those following K&R and those following the
recent Unix compilers.  You really do need two different standard, or
two different levels.

As an aside, I was very involved in Cobol work for a major manufacturer
at about the time the multi level standard became official.  This
standard forced a lot of manufacturers to upgrade their compilers, not
because the standard required it, but because being standard to a lower
level was a sales disadvantage and because having the higher level
defined told the management exactly what was needed to fix the problem.

I strongly believe that the best way to cause improvements in the state
of the art is to make a two level standard and let market forces work on
those on the lower level.

                              Paul