Path: utzoo!attcan!uunet!lll-winken!ames!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.fortran
Subject: Re: An exercise in futility
Keywords: portability vs vendor_extensions the_Brooks_Report
Message-ID: <15345@mimsy.UUCP>
Date: 8 Jan 89 09:38:39 GMT
References: <585@mbph.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 67

(I have deleted misc.legal as that group appears irrelevant.)

In article <585@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics
SM) writes:
>Sections 1.3.2.(4) and 1.4 are irreconcilable with section 1.1.

Not so.

(1.3.2.(4) and 1.4 have to do with extensions and erroneous programs,
while 1.1 says that the standard is to promote portability.)

>The key word in section 1.1 is _portability_; the intent is to provide
>horizontal portability among many different machines.  Sections
>1.3.2.(4) and 1.4 allow implementors to _extend_ the language in
>any way they want--spawning a plethora of dialects.

No: extensions must not conflict with the standard.  They may not be
arbitrary.  They may only make erroneous programs correct; they may
not make correct programs erroneous.

>... let me give a real example.  I am currently porting
>some fortran code that produced the following diagnostic:
>        Common /control/ <====  natoms
>        ****Error: Identifier too long

This is not FORTRAN code.  Had it been legal F77 code, it would say
something like

	COMMON /CONTRO/ NATOMS

>Section 18 states the a "symbolic name consists of one to six, 
>alphanumeric characters, the first of which must be a letter."

All well and good.

>Checking the **X blue book, we learn that a symbolic name can
>be 31 characters long.  My compiler strictly enforces the
>existing standard as you can see above.  By allowing **X to
>market its extended compiler, the standards committee has
>abandoned their stated intent to provide a horizontally
>portable fortran language standard!

Not at all.  That someone made use of a 31-character extension does not
mean that F77 programs are not portable; it merely means that someone
wrote something that is not an F77 program.  Perhaps the person that
wrote the program you are porting did not care about portability.  He
may well have used system-specific subroutine libraries as well.
Again, the F77 standard cannot prohibit this.  All it can do is provide
one collection of things which, if used without extensions, guarantees
portability.  Your /control/ programmer stepped outside the provided
collection by using a seven-character name.  That one exception alone
invalidates the applicability of the entire F77 standard.

>They are not serving the user community.

That is possible: I myself consider the six-character limit an
abomination.  (It is one reason---though far from the only one---that I
do not write F77 programs.  It may keep me from writing ANSI C programs
as well.)  The F77 standard might better have served the user community
by demanding a larger minimum.  The user community had a chance to ask
the original ANSI committee to do this (as the user community had a
chance with X3J11, the C standards committee).  Some probably did; but
not enough, and manufacturers (and ANSI committees) seem to be
extremely reluctant to change.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris