Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!bloom-beacon!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert
From: hirchert@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: Summary of Additions to Fortran 8x
Message-ID: <50500027@uxe.cso.uiuc.edu>
Date: 4 Feb 88 18:41:00 GMT
References: <68000007@convexc>
Lines: 83
Nf-ID: #R:convexc:68000007:uxe.cso.uiuc.edu:50500027:000:3756
Nf-From: uxe.cso.uiuc.edu!hirchert    Feb  4 12:41:00 1988


Steve Rowan (rowan@convexc) provides a summary of the major new featuers of Fortran 8x and
then comments on them.  I won't respond to all of his comments (I even agree
with some of them!), but I will respond to his comments in an area that is most
interesting to me:
> Modular Definitions:
>
>   MODULE POOL1
>      INTEGER X(1000)
>      REAL Y(100,100)
>   END MODULE
>
>
>   USE POOL1
>
>
>     Allows for better modularization of programs.  Interface errors between
>     modules will be caught at compile/link time.
>
>   Issues:
>
>    1.  The dependent compilation model has not been tested in the FORTRAN
>	 arena and is not like the Ada dependent compilation.
No, its more like the dependent compilation model I have seen in many
assemblers - write out a binary symbol table and retrieve it later.
>    2.  Increases compilation complexity and requires changes in other
>	 areas of the system software such as the linkers and loaders.
The compiler needs to be able to
a. write out the symbol table of a MODULE (presumably in binary)
b. use the Fortran name of the MODULE to determine where to write the symbol
   table (and thus where to retrieve it later)
c. read the binary symbol table written earlier
d  merge the symbol table read with the active symbol table in the current
   program unit (non-trivial because of the rename options, but not terribly
   difficult, either)
With those added capabilities, the rest of handling MODULE/USE is essentially
identical to the handling of either entities declare locally or in COMMON.
This strikes me as only a marginal increase in compilation complexity,
especially when compared with compilation tasks such as data flow optimization
or vectorization.  There is no reason for the linkers or loaders to have any
special knowledge of MODULEs.  (Many linkers and loaders will have to modified
to handle the switch from 6 character names to 31 character names, and there
are useful things that these processors _could_ do with special knowledge of
MODULEs, but such knowledge is not required!)
>    3.  Will cause compilers to be slower.  Some argue that faster machines
>	 will overcome this, but if I have a FORTRAN 77 and a FORTRAN 8x
>	 compiler on the same machine, the FORTRAN 8x compiler will have to,
>	 by definition of the standard, do more work to compile the same   
>	 program.  
I would expect that reading useful information in binary would be _faster_
than reinterpreting the text that defines it.  Why do you expect it to be
slower?  (I would agree that there are features in Fortran 8x that might make
it slower to compile than FORTRAN 77; this just isn't one of them.)
>    4.  The INCLUDE statement, which performs the function of allowing a 
>	 single definition of common code, is NOT a part of this proposed
>	 standard.  
True.  USE is expected to be faster (see above), more flexible (USE of selected
symbols and symbol renaming), more portable (Fortran name used rather than
processor-dependent file name), and more reliable (the meaning of the symbols
imported can't be changed by other declarations in the importing program unit)
than INCLUDE.
>
>Everyone has the right to form their own opinion about the proposed FORTRAN
>8x standard.  Remember that if you are going to give your opinion in 
>writting to the committee, that letters must be received in Washington DC
>by February 23, 1988.  The address is:
>
>          X3 Secretariat
>	  ATTN:  Gwendy Phillips
>	  Computer and Business Equipment Manufacturers Association
>	  Suite 500
>	  311 First Street, NW
>	  Washington, DC   20001-2178
Amen.
>
>
>
>
>Steve Rowan
>Convex Computer Corp.
>{allegra,ihnp4,uiucdcs}!convex!rowan
>(214)952-0332
Kurt W. Hirchert          National Center for Supercomputing Applications