Path: utzoo!utgpu!watmath!att!dptg!rutgers!cs.utexas.edu!uunet!dino!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert
From: hirchert@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: Two Fortran Standards
Message-ID: <50500147@uxe.cso.uiuc.edu>
Date: 30 Aug 89 23:04:49 GMT
References: <282@unmvax.unm.edu>
Lines: 61
Nf-ID: #R:unmvax.unm.edu:282:uxe.cso.uiuc.edu:50500147:000:3282
Nf-From: uxe.cso.uiuc.edu!hirchert    Aug 29 13:00:00 1989


Walt Brainerd and Presley Smith are engaged in an argument about whether
FORTRAN 77 is a true subset of Fortran 8x.  Allow me to try to clarify the
situation:

Fortran 8x is a superset of FORTRAN 77 in the following sense:  A standard-
conforming Fortran 8x processor should interpret any program in a manner
consistent with the requirements of FORTRAN 77.


Implicit is the above are two limitations:

1. It was possible under FORTRAN 77 for a program to be standard conforming
   on one processor, but not standard conforming on another.  The classic
   example of this is a program which uses an external function without
   specifying it in an EXTERNAL statement.  If such a program is moved to a
   processor where that particular function name has been made an intrinsic,
   the new processor will interpret those function references as references to
   its processor-dependent intrinsic and thus conclude that the program does
   not conform to FORTRAN 77.

   In such cases, it is possible that the program will not be regarded as
   standard conforming by any Fortran 8x processor and/or the program may have
   a different interpretation because of the differing semantics of the
   added intrinsic functions.

2. There are cases where FORTRAN 77 gave a conforming processor a choice of
   interpretations and Fortran 8x may be more limiting.  For example, there
   are situations involving the ends of files that in FORTRAN 77 could have
   been interpreted as errors but that in Fortran 8x must raise the end-of-file
   condition.  All interpretations allowed by Fortran 8x are also allowed by
   FORTRAN 77, but not all interpretations allowed by FORTRAN 77 are also
   allowed by Fortran 8x.

The above two limitations are the reason a FORTRAN 77 program cannot be
guaranteed to have the same interpretation when run on a Fortran 8x -- it may
not have been possible to guarantee that they would have the same
interpretation when run on another FORTRAN 77 processor!

In other words, truly portable FORTRAN 77 programs will remain portable in
Fortran 8x, but if a program has exploited the processor-dependent aspects of
FORTRAN 77, then it is possible that the same processor-dependent behavior
will not be available and the program will fail under Fortran 8x.

The examples cited from section 1.4.1 are _not_ example of incompatibilities
between FORTRAN 77 and Fortran 8x; they _are_ examples of places where a
Fortran 8x processor might be forced to behave differently from an existing
FORTRAN 77 processor based on the same hardware.

I agree with Presley that the words "with the same interpretation" should
not appear in section 1.4.1.  Fortran 8x can guarantee the same interpretation
only in those cases where FORTRAN 77 guaranteed that two different FORTRAN 77
processors would have the same interpretation.  Nevertheless, the assertion
remains that there are no known examples of programs where FORTRAN 77
processors would be required to have the same interpretation, but a Fortran 8x
processor would have a different interpretation.  Presley, are you aware of
any examples that contradict _this_ assertion?  (As stated above, the
examples in 1.4.1 do not qualify.)

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications