hirchert@uxe.cso.uiuc.edu (03/10/88)
There appears to be some confusion about the implementation implications of MODULE/USE: 1. If you don't make use of MODULE/USE, then your program should be independently compilable just as it was in FORTRAN 77. 2. Even if you do use MODULE/USE, it should remain possible to separately compile the various program units in your program. 3. The dependency introduced by MODULE/USE is essentially equivalent to that introduced by the INCLUDE statement: To compile a program unit containing an INCLUDE statement, you must first make the information available by putting it in a file with the appropriate name. To compile a program containing a USE statement, you must first make the information available by compiling the MODULE being referenced. 4. Properly implemented, MODULE/USE should be faster than INCLUDE because it bypasses the need to repeatedly convert textually represented information into the form it is used internally by the compiler. (This is analogous to the fact that unformatted input/output is faster than formatted input/output.) I do not consider INCLUDE an adequate replacement for MODULE/USE. I would not object to having INCLUDE in addition to MODULE/USE, but most people seem to object to the redundancy inherent in that kind of combination. Kurt W. Hirchert National Center for Supercomputing Applications
mcdonald@uxe.cso.uiuc.edu (03/10/88)
>I do not consider INCLUDE an adequate replacement for MODULE/USE. I would not >object to having INCLUDE in addition to MODULE/USE, but most people seem to >object to the redundancy inherent in that kind of combination. >Kurt W. Hirchert National Center for Supercomputing Applications There is still a positive need for INCLUDE that is not met by MODULE/USE. That is inclusion of such things as code fragments and other things which don't fit the allowed syntax of a module. It is not redundant. INCLUDE allows ANYTHING in it, even just part of a statement. This is very important since F8x does not have macros or defines.
hirchert@uxe.cso.uiuc.edu (03/11/88)
Professor McDonald writes >>I do not consider INCLUDE an adequate replacement for MODULE/USE. I would not >>object to having INCLUDE in addition to MODULE/USE, but most people seem to >>object to the redundancy inherent in that kind of combination. > >>Kurt W. Hirchert National Center for Supercomputing Applications > >There is still a positive need for INCLUDE that is not met by MODULE/USE. >That is inclusion of such things as code fragments and other things which >don't fit the allowed syntax of a module. It is not redundant. INCLUDE >allows ANYTHING in it, even just part of a statement. This is very important >since F8x does not have macros or defines. 1. The MIL-STD-1753 INCLUDE statement (which is what many vendors have chosen to implement) does NOT allow the inclusion of partial statements. 2. In many (but not all) cases, included code fragments can be replaced by references to internal or module procedures. If the compiler supports in-line expansion of such procedures (as most compilers do for statement functions), efficiency need not be lost. (However, it would probably be inefficient to expand all internal procedures in-line, and Fortran 8x provides no standard way to indicate which should and which shouldn't. I never claimed that Fortran 8x was perfect.) 3. I did not mean to give the impression that I thought INCLUDE was 100% redundant with respect to MODULE/USE. I would suggest that, in practice, it is something like 99% redundant. (In other words, most uses of INCLUDE are not for the purposes Professor McDonald is concerned about.) The issue is whether the 99% redundancy is justified by the 1% of nonredundancy (or by the need to "standardize existing practive"). Kurt W. Hirchert National Center for Supercomputing Applications
reeder@ut-emx.UUCP (William P. Reeder) (03/12/88)
In article <50500031@uxe.cso.uiuc.edu>, hirchert@uxe.cso.uiuc.edu writes: > I do not consider INCLUDE an adequate replacement for MODULE/USE. I would not I think you have it backwards, lots of compilers *already* have INCLUDE, none (that I know of) have MODULE/USE. Therefore, MODULE/USE would be replacing INCLUDE. Now tell me that DEC and CRAY and all those other compiler vendors are going to delete INCLUDE from their next versions of the compilers. Also, since the MODULE name is not a filename, how do you (in a standard way, of course) tell the compiler where to find the file containing the MODULE? (I remember a reply to a letter ballot where it was claimed that non-standardization of filenames was one thing that prohibited INCLUDE from being standardized. Of course that argument didn't stop the OPEN statements from being included in the standard with the FILE= clause.) I will concede your point about compilation time. But I don't think any of the "benefits" of MODULE justify using it instead of INCLUDE. > Kurt W. Hirchert National Center for Supercomputing Applications -- William {Wills,Card,Weekly,Virtual} Reeder reeder@emx.utexas.edu The Looniversity of TexMex at Autism, Consternation Central, Austin TX 78712 DISCLAIMER: I speak only for myself, and usually only to myself.