Xref: utzoo comp.lang.fortran:1682 misc.legal:6925
Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!ucsfcgl!cca.ucsf.edu!ccb.ucsf.edu!dick
From: dick@ccb.ucsf.edu (Dick Karpinski)
Newsgroups: comp.lang.fortran,misc.legal
Subject: Re: An exercise in futility
Summary: It can work, if you want.
Keywords: portability vs vendor_extensions the_Brooks_Report
Message-ID: <1581@ucsfcca.ucsf.edu>
Date: 8 Jan 89 21:13:47 GMT
References: <585@mbph.UUCP>
Sender: root@cca.ucsf.edu
Reply-To: dick@ucsfccb.UUCP (Dick Karpinski)
Organization: UCSF Computer Center
Lines: 76

In article <585@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
>
>}	1.1 _Purpose_
>}
>}	    [...] The purpose of this standard is to promote
>}           portability of FORTRAN programs for use on a variety
>}           of data processing systems.

While it is not explicit here, the standard is intended to permit
the construction and use of portable programs, not to require that.

If your compiler accepts legal portable programs, then the standard
has done its job.  If you write programs which follow the standard
and do not use your vendor's extensions so that you can achieve the
protability that you desire, then the standard has done its job.

>Sections 1.3.2.(4) and 1.4 are irreconcilable with section 1.1.

Not at all.  More restrictive standards would not be as respected
by vendors since often they only care about porting things to their
systems.  Some of the better vendors provide compiler switches to
demand standard conforming programs.  My advice it to get one of
those and require that programs be tested in that way before they
are accepted as complete.  This CAN ensure that programs are 
(mostly) portable.

>I am not opposed to extending the
>language.  However, I strongly oppose the chaotic mechanism
>codified in sections 1.3.2.(4) and 1.4!

You might be surprised how often you choose order over freedom.
I am.

>How do the courts interpret a contract containing such
>contradictory clauses?  

Courts try to avoid ruling on such things.  If some experts
testify that they are not contradictory, as I would, the court
will tend to agree.  Courts feel safer that way.

>First, 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
>Section 18 states the a "symbolic name consists of one to six, 
>alphanumeric characters, the first of which must be a letter."
>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!  They are not serving the
>user community.  Incidentally, this is an extension that I believe
>should have been added to the Language Standard many, many
>years ago.

Here you have it.  You say the standard fails when it is obvious
that the code you are porting was not written to the standard.
The implication is that you believe that no compiler should have
permitted long names until the standard permitted it.  At that
time, presumably, all compilers would have been required to accept
long names.  Not very easy to accomplish, and that would have
meant that no experience with compilers accepting long names 
would be available to the standards committee when they decided
to permit them.  Sounds pretty risky to me!  I like it better
the way it is: those who think it wise do it.  If it works out
well, they come back to the standards committee and advocate it
for everybody else too.  Much nicer.

Dick

Dick Karpinski  Manager of Minicomputer Services, UCSF Computer Center
UUCP:  ...!ucbvax!ucsfcgl!cca.ucsf!dick        (415) 476-4529 (11-7)
BITNET:  dick@ucsfcca or dick@ucsfvm           Compuserve: 70215,1277  
USPS:  U-76 UCSF, San Francisco, CA 94143-0704   Telemail: RKarpinski   
Domain: dick@cca.ucsf.edu  Home (415) 658-6803  Ans 658-3797