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