Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tektronix.UUCP
Path: utzoo!utcs!lsuc!pesnta!hplabs!tektronix!robertd
From: robertd@tektronix.UUCP (Bob Dietrich)
Newsgroups: net.lang
Subject: Re: Standardization
Message-ID: <5125@tektronix.UUCP>
Date: Tue, 12-Feb-85 18:52:48 EST
Article-I.D.: tektroni.5125
Posted: Tue Feb 12 18:52:48 1985
Date-Received: Thu, 14-Feb-85 11:53:37 EST
References: <283@gumby.UUCP>
Organization: Tektronix, Beaverton OR
Lines: 58

> Indeed, there is no accepted standard for Pascal.  The original is
> incomplete, and the extensions are largely incompatible.  Why does
> this happen?  Is it bad?  How can it be avoided (if bad)? These are far
> more interesting topics than the current low-content argument about 
> whether Original C is different from Current C (this is true for any 
> language I can recall), or whether an ISO Standard is a standard
> (clearly in some sense it is).
> ... 
> 				-- Mike Inners
 
My first reaction is to object violently to you opening statement, but I get
the impression you are talking about "standard" and "incomplete" in highly
subjective terms. Whether you personally accept it or not, standards exist for
Pascal for both the ANSI/IEEE and ISO versions.

Turning to "standard" and "incomplete", you seem to saying that the feature
set of Pascal processors is not identical from processor to processor. Further-
more, you seem to be saying that Jensen & Wirth Pascal is not complete because
it doesn't have an 'otherwise' clause in the case statement, etc. Correct me if
I'm wrong.

As far as your definition of "standard" goes, I agree this is the case. For
better or worse, this is how one Pascal product (or for that matter, a FORTRAN
product, LISP product, database product, etc.) is differentiated from other
Pascal products. Customers look at features first, and this is also how
new features become a standard part of the language. When FORTRAN 77 was
standardized, most of the feature differences between it and FORTRAN 66 were
extensions in several FORTRAN 66 compilers. The only languages I know of that
do not have this problem (or feature) have only one implementation, a single
implementor, or the language is Ada. People seem to either take the position
that DoD's "no subset" rule for Ada will be ignored, or else kill the language.

I have found that "incomplete" is measured by the person speaking and by
the acceptance of new programming ideas over time. I have had many people
(myself included) say "Language X would be PERFECT  ... if only it had features
a, b and c." Someone else says "Language X would be FANTASTIC ... if only it
only had b, e, and f." The problem is, the union of everyone's "minimal"
extensions is alphabet soup and a gargantuan user's manual. Who is right?

Like anything that must be constructed, the implementation of programming
languages usually is finished about the time the ideas that spawned the
language are obsolete. Furthermore, the ideas behind the implementation are
not widely accepted until the implementation is widely used or publicized
("Prove it!"). Thus, it's very easy to judge yesterday's language with
today's ideas, and come up with the verdict "incomplete".

One other point is that the whole idea of standardization (formally or
informally) is to freeze a set of ideas into something that people can use
for some period of time without it changing. This results in something like
FORTRAN having millions of lines of code available, seeming immortal, and
at the same time regarded as antiquated.

                                              Bob Dietrich
                                              Tektronix, Inc.
                                              (503) 629-1727
{ucb or dec}vax!tektronix!robertd             uucp address
robertd@tektronix                             csnet address
robertd.tektronix@rand-relay                  arpa address