Xref: utzoo comp.lang.fortran:1680 misc.legal:6924
Path: utzoo!attcan!uunet!lll-winken!ames!haven!umbc3!mbph!hybl
From: hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM)
Newsgroups: comp.lang.fortran,misc.legal
Subject: Re: An exercise in futility
Keywords: portability vs vendor_extensions the_Brooks_Report
Message-ID: <585@mbph.UUCP>
Date: 7 Jan 89 22:26:20 GMT
Organization: University of Maryland, School of Medicine, Baltimore, MD 21201
Lines: 105


In message <3704@s.cc.purdue.edu> ags@s.cc.purdue.edu (Dave Seaman
Purdue University) writes:
> In article <584@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl  Dept of
> Biophysics  SM) writes:
> >I think that the committee is without real power!  They
> >can not enforce the standard so their panegyrist says
> >'When the code is WRONG, the compilers are allowed to
> >do whatever they want.'  If the name FORTRAN is not a
> >registered trademark, anyone can use it to sell anything.
> ----------------------------------------------------------------
> 
> Apparently you would prefer that the committee be selective in
> which parts of the standard they should enforce.  In particular,
> you would like for them to ignore:  <***** The lines prefixed by
 '}' were added by me for completeness. (A.Hybl)
> 
}	1.1 _Purpose_
}
}	    [...] The purpose of this standard is to promote
}           portability of FORTRAN programs for use on a variety
}           of data processing systems.
}
}	    [...]
}
> 	1.3.2. _Exclusions_.  This standard does not specify:
> 
> 	    [...]
> 
> 	  (4) The results when the rules of this standard fail
> 	      to establish an interpretation.
> 
> and:
> 
> 	1.4. _Conformance_
> 
> 	  [...]
> 
> 	A processor conforms to this standard if it executes
> 	standard-conforming programs in a manner that fulfills the
> 	interpretations prescribed herein.  A standard-conforming
> 	processor may allow additional forms and relationships
> 	provided that such additions do not conflict with the
> 	standard forms and relationships.  [...]
> 
> --------------------------------------------------------------------
> If you want to lobby for this part of the standard to be
> changed, that is certainly your right.  But to accuse the
> committee of "not enforcing the standard" PRECISELY BECAUSE
> THEY ARE ENFORCING THE STANDARD seems like twisted logic to me.
> 
Sections 1.3.2.(4) and 1.4 are irreconcilable with section 1.1.
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.  Sections
1.3.2.(4) and 1.4 are antithetical to promoting a horizontal
portable language standard.  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!

How do the courts interpret a contract containing such
contradictory clauses?  I have cross posted this message to
newsgroup misc.legal.  Perhaps some good soul will contribute
a legal opinion on this issue.

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.

In House Report No. 94-1746 titled "Administration of Public
Law 89-306, Procurement of ADP Resources by the Federal
Government," we read: "This means that a user agency may adopt
Cobol but employ unique features which will impede conversion."
That was written in 1976.  You can replace the word Cobol with
Fortran and the word "conversion" with "portage" and notice
that nothing has changed over the last thirteen years.  The
Brooks committee added:  "Only when standard high level
languages are developed and their use enforced will a barrier
to effective competition be eliminated."

Unless section 1.3.2.(4) is deleted and section 1.4 suitably
amended, any hope for having a horizontally portable fortran
language standard is _ignis fatuus_.  Was the Brooks report
an exercise in futility?
  
----------------------------------------------------------------------
Albert Hybl, PhD.              Office UUCP: uunet!mimsy!mbph!hybl
Department of Biophysics       Home   UUCP: uunet!mimsy!mbph!hybl!ah
University of Maryland                CoSy: ahybl
School of Medicine
Baltimore, MD  21201                 Phone: (301) 328-7940 (Office)
----------------------------------------------------------------------