Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!ukma!tut.cis.ohio-state.edu!cs.utexas.edu!oakhill!steve
From: steve@oakhill.UUCP (steve)
Newsgroups: comp.lang.fortran
Subject: A New Way To Write Old Standards (Or: An exercise in futility)
Summary: OK, Let's solve this problem
Keywords: Standard standardization ambiguity revision
Message-ID: <1760@devsys.oakhill.UUCP>
Date: 3 Jan 89 19:46:20 GMT
References: <583@mbph.UUCP>
Organization: Motorola Inc. Austin, Tx
Lines: 74

In article <583@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
> 
> Steve has shown that the USENET can be used to rapidly discover
> ambiguities in a language standard.  Discussions in this newsgroup  
> can propose corrective language to eliminate ambiguities from
> the standard.  The real problem is how to incorporate the new
> language in a standard that has been chiseled in stone?  Must
> we wait for FORTRAN8x? :-(
> 
> After our law makers write and pass laws, the laws appear in a
> publication of state or federal statutes.  The legislature
> will try to correct a discovered flaw or ambiguity in a law
> during their next session.  In rare cases, a special
> session may be called to tackle the problem.  Ambiguities in
> the law can also be resolved by the courts.  All new laws,
> recently revised laws and notes of court cases are placed in
> the "Cumulative Annual Pocket Part" which is placed in the
> back of the appropriate volume of the statutes.
> 
> The purpose of the Fortran ANSI X3.9 1978 standard "is to
> promote portability of FORTRAN programs for use on a variety
> of data processing systems."  The result of Steve's survey
> shows that not even a simple double do loop is immune to
> ambiguity when tested for horizontal portability.  His example
> and others (see Fortech Forum, Vol 2 pages 5-6; Fortran
> Forum, Vol 4 pages 19-20 and Fortran Forum Vol 6 pages 10-11)
> proves that computer language standards need a "Cumulative
> Annual Pocket Part."  Without it, the hope for a horizontally
> portable standard is an exercise in futility.
> 

Ok, I think I proved my point.  We have a big hole in our
standardization process.  And I think the problem is four-fold.

1) We need to come up with a way to create standards that solve our
   problems.  Our current system seems fine, execept see number
   four below.  Many times it seems that standards are started
   years after people realized there are needs for them.  Our
   current process needs to be more timely.

2) We need a way for ambiguity to be answered in a continual way
   once the standard is out.  If there was such a way, the question
   of 'Dubious Fortran Construct' could be sent out, evaluated and
   the unambigous interpretaion answered and published.

3) We need a way to gradually bring a language up to date.  These jumps
   from F66 to F77 to F8x are too jarring.  They cause a revolt everytime
   they happen, wheather the revolt is necessary or not.

4) We need a way to revolt against The Powers That Be (TPTB)  when they
   force on us a standard (or ruling in #2) that is not to our liking.
   If they issued a ruling that 'Dubious Fortran Construct' was illegal, and
   most programmers disagreed, a mechanism must be in place to protest.
   And TPTB that be must be responsive. I think the mechanism is somewhat
   there, but the responsiveness isn't.

OK, I think I've laid some grounds for discussion here.  Let's discuss.

                   enough from this mooncalf - Steven

P.S.  Since I come from a legal family I have no problem with a bi-headed
legistrative, judical system.  One continuating pulling in new theory and
users comments for a new standard every ~18 months, the other head coming
up with the interpretations of the standard.  Revolts could be settled
by having the standard writers address the function in their next standard.
Of course the man power and time required for this is out of the question.
----------------------------------------------------------------------------
These opinions aren't necessarily Motorola's or Remora's - but I'd like to
think we share some common views.
----------------------------------------------------------------------------
Steven R Weintraub                        cs.utexas.edu!oakhill!devsys!steve
Motorola Inc.  Austin, Texas 
(512) 440-3023 (office) (512) 453-6953 (home)
----------------------------------------------------------------------------