Path: utzoo!utgpu!watmath!att!dptg!rutgers!usc!cs.utexas.edu!uunet!microsoft!bobal
From: bobal@microsoft.UUCP (Bob Allison)
Newsgroups: comp.lang.fortran
Subject: Re: Two Fortran Standards
Message-ID: <7560@microsoft.UUCP>
Date: 30 Aug 89 17:59:27 GMT
References: <308@unmvax.unm.edu> <1608@convex.UUCP>
Reply-To: bobal@microsoft.UUCP (Bob Allison)
Organization: Microsoft Corp., Redmond WA
Lines: 54

>In article <308@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes:
>>In article <1598@convex.UUCP>, psmith@mozart.uucp (Presley Smith) writes:
>  
>Walt is right... It was only changed in one place, in the introduction, which
>now reads:
>

Yeah, when Walt mentioned that, I ran around and checked the
minutes and the action was never even recorded.  I was there, and the
intent was clearly to remove that phrase from the draft.  Whoever
suggested the wording messed up.  It should be a simple editorial change
to fix up, especially in light of the fact that later in the paragraph
it shows examples of places where standard-conforming 77 programs do not
have the same interpretation.  They also missed the new specification that
leading zeroes are insignificant in STOP and PAUSE statements (I know, 
big deal).  I'll have to sit down and think about it, but I feel like
there were others also.

The change to page i was in response to allowing the change in interpretation
of constants in DATA statements.  Jerry Berkman has indicated that he
prefers such changes, since they reduce the number of uncertainties when
coding and I agree.  However, I still feel (and yes, I am being picky) that
these changes disqualify any attempt to make FORTRAN 77 a subset of Fortran 8x.
It isn't a political point of view, but rather a technical one: FORTRAN 77 is
not a proper subset of 8x.  It is a political solution to make it a subset,
in the face of evidence to the contrary.

>
>The standard documents all the KNOWN examples in 1.4.1.  In this complex
>document, I expect that implementers will find several more when someone
>really attempts to implement this...
>

Oh, no doubt.  That doesn't mean the changes weren't for the better; most
of the time they will have been.  

Keith Bierman noted that most of the people in favor of keeping 77 as a
standard will continue to vote NO on 8x.  I feel it really hasn't been
put to the test yet, and honestly believe that I would be in favor of
more radical changes if I knew 77 was still going to be a standard.
Most of my concern with 8x is that it is a very different, very new
language being forced on people who have no other choice if they currently
code in 77.

It may be true that keeping 77 will slow down production of 8x compilers,
but I'm not sure I believe it.  Vendors who don't want to produce an 8x
compiler won't do so until market pressure becomes intense.  Companies
like Sun, who are hungry and tend to try to embrace standards up front,
will still produce an 8x compiler.  People will either embrace 8x compilers
and force everyone else aboard, or not.  The presence of 77 as a standard
doesn't really seem to affect that much, unless 8x is a bomb.  In which case
it is a very welcome island of stability and portability.

Bob Allison