scavo@cie.uoregon.edu (Tom Scavo) (01/04/91)
I use PARAMETERs to specify the bounds on array indices, and then pass these constants along with the arrays so that the subprograms know how to dimension them. Of course, with one- dimensional arrays there's absolutely no problem (because I don't need to pass array bounds anyway), but multi-dimensional arrays can be a real pain. Does anyone know how to make these PARAMETERs global so that subprograms have instant access to them, thereby obviating the need for all those arguments? Common doesn't seem to work on PARAMETERs. There must be a better way... Tom Scavo scavo@cie.uoregon.edu
gary@cgdisis.cgd.ucar.edu (Gary Strand) (01/04/91)
> Tom Scavo > Does anyone know how to make these PARAMETERs global so that subprograms > have instant access to them, thereby obviating the need for all those > arguments? Common doesn't seem to work on PARAMETERs. Well, without knowing if your FORTRAN has this extension, try using "include" files, just like in C. That way, you only have to change them in one file, and 'make' will recompile all the programs that use it (ie, the include file). -- Gary Strand There is only one success -- to be able Internet: strandwg@ncar.ucar.edu to spend your life in your own way. Voicenet: (303) 497-1336 - Christopher Morley
mac@harris.cis.ksu.edu (Myron A. Calhoun) (01/05/91)
In article <1991Jan4.022750.24875@ariel.unm.edu> you write: >I use PARAMETERs to specify the bounds on array indices, and >then pass these constants along with the arrays so that the >subprograms know how to dimension them. Of course, with one- >dimensional arrays there's absolutely no problem (because I >don't need to pass array bounds anyway), but multi-dimensional >arrays can be a real pain. >Does anyone know how to make these PARAMETERs global so that >subprograms have instant access to them, thereby obviating >the need for all those arguments? Common doesn't seem to >work on PARAMETERs. Routines in my large f77 programs commonly have THREE include statements: INCLUDE 'parameters' INCLUDE 'declarations' INCLUDE 'commons' for the global parameters, declarations, and common statements. I use three so that additional declarations (INTEGER, DATA, etc.) can be inserted where they belong between or following the INCLUDE's. I, too, would like to see a "global" PARAMETER statements, but since FORTRAN permits separate compilations, such globals probably are just not possible. --Myron. -- # Myron A. Calhoun, Ph.D. E.E.; Associate Professor (913) 539-4448 home # INTERNET: mac@cis.ksu.edu (129.130.10.2) 532-6350 work # UUCP: ...{rutgers, texbell}!ksuvax1!harry!mac 532-7353 fax # AT&T Mail: attmail!ksuvax1!mac W0PBV @ K0VAY.KS.USA.NA
maine@elxsi.dfrf.nasa.gov (Richard Maine) (01/05/91)
On 4 Jan 91 16:52:23 GMT, mac@harris.cis.ksu.edu (Myron A. Calhoun) said: Myron> In article <1991Jan4.022750.24875@ariel.unm.edu> you write: >Does anyone know how to make these PARAMETERs global so that >subprograms have instant access to them, thereby obviating >the need for all those arguments? Common doesn't seem to >work on PARAMETERs. Myron> I, too, would like to see a "global" PARAMETER statements, but since Myron> FORTRAN permits separate compilations, such globals probably are just Myron> not possible. Fortran 90 modules can contain "global" parameters, among other things. Sample code follows (quickly thrown together, so pardon if there is something not quite right). module some_parameters integer, parameter :: max_things=100 integer, parameter :: max_other_things=50 end module some_parameters subroutine do_it use some_parameters real :: a(max_things), b(max_other_things) ... end subroutine do_it There are, as you might guess, some implications to "separate compilation". The some_parameters module must be "available" when the do_it routine is compiled. Used like this, the module looks little different from an "include" other than syntactic details, plus of course the advantage that modules are standard in F90 (though so are includes). This is a very limitted example; there are lots of other "neat" things that can be done with modules, some of them having no direct F77 comparisons. Another way to use modules for this kind of application is to put all the subroutines that share information into a module as follows (in the extreme case, this module can legally contain every subroutine in the program, but of course, that's poor form except in small programs). module something integer, parameter :: max_things=100 integer, parameter :: max_other_things=50 contains ... subroutine do_it real :: a(max_things), b(max_other_things) ... end subroutine do_it end module something All the subroutines in this module share the parameters (or other data) declared above the "contains". And you can combine these two ways of using modules so that you don't have to put everything into one module, yet you also don't need a "use" in every subroutine. Sample (referencing the above some_parameters module). module something use some_parameters contains ... subroutine do_it real :: a(max_things), b(max_other_things) ... end subroutine do_it end module something Of course, F90 lessens (but does not eliminate) the need for parameters declaring matrix dimensions because 1. You would dynamically allocate some matrices as needed, instead of dimensioning them to fixed maximum sizes. 2. Matrices in argument lists automatically carry size information along with them; you don't have to do it separately. (Much like character string lengths are automatically passed in F77). Til F90 "arrives" for real, variants of the non-standard include statement and/or source code preprocessors (possibly to implement the inclusion) seem the only realistic options for global parameters. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.64.6]
scavo@cie.uoregon.edu (Tom Scavo) (01/06/91)
Thanks to all who responded by e-mail (mwette@csi.jpl.nasa.gov, jrbd@craycos.com, richard@calvin.ee.cornell.edu, moulton@cs.utk.edu, and pmontgom@math.ucla.edu). Almost without exception, I was advised to use include files for global constants and variable declarations. Tom Scavo scavo@cie.uoregon.edu
fox@DASHER.NSCL.MSU.EDU (01/07/91)
In article <1991Jan4.165223.7212@maverick.ksu.ksu.edu>, mac@harris.cis.ksu.edu (Myron A. Calhoun) writes... >In article <1991Jan4.022750.24875@ariel.unm.edu> you write: >>I use PARAMETERs to specify the bounds on array indices, and >>then pass these constants along with the arrays so that the >>subprograms know how to dimension them. Of course, with one- >>dimensional arrays there's absolutely no problem (because I >>don't need to pass array bounds anyway), but multi-dimensional >>arrays can be a real pain. > >>Does anyone know how to make these PARAMETERs global so that >>subprograms have instant access to them, thereby obviating >>the need for all those arguments? Common doesn't seem to >>work on PARAMETERs. > >Routines in my large f77 programs commonly have THREE include statements: > > INCLUDE 'parameters' > INCLUDE 'declarations' > INCLUDE 'commons' > >for the global parameters, declarations, and common statements. I use >three so that additional declarations (INTEGER, DATA, etc.) can be >inserted where they belong between or following the INCLUDE's. > >I, too, would like to see a "global" PARAMETER statements, but since >FORTRAN permits separate compilations, such globals probably are just >not possible. >--Myron. >-- .. and since INCLUDE is not part of the FORTRAN-77 standard, there's no portable way to get the effect of a global parameter statement. A question to those following FORTRAN-9x.. how is this problem dealt with (if at all) in that language? Ron Ron Fox | FOX@MSUNSCL.BITNET | Where the name NSCL | FOX@CYCVAX.NSCL.MSU.EDU | goes on before Michigan State University | MSUHEP::CYCVAX::FOX | the quality East Lansing, MI 48824-1321 | | goes in. USA
ubiquity@cs.utexas.edu (Richard Hoffman) (01/07/91)
In article <1991Jan7.131620.27789@msuinfo.cl.msu.edu> fox@DASHER.NSCL.MSU.EDU writes: >.. and since INCLUDE is not part of the FORTRAN-77 standard, there's no >portable way to get the effect of a global parameter statement. One way to get a semi-portable INCLUDE *anywhere* is to use the C preprocessor. You don't have to know anything about C, except for the rules of #include itself. C is widely available, so most installations will have it. I have frequently used it with FORTRAN, and also the C #define statements, which I find much more convenient than PARAMETER statements. It does add an extra step to program preparation, though. -- Richard Hoffman IBM Entry Systems Division (512) 823-1822 1529 Ben Crenshaw Way Austin, TX 78746 "Life is a gamble at terrible odds; (512) 327-9232 if it were a bet you wouldn't take it" (Tom Stoppard)
burley@geech.ai.mit.edu (Craig Burley) (01/07/91)
In article <1991Jan7.131620.27789@msuinfo.cl.msu.edu> fox@DASHER.NSCL.MSU.EDU writes:
.. and since INCLUDE is not part of the FORTRAN-77 standard, there's no
portable way to get the effect of a global parameter statement. A question
to those following FORTRAN-9x.. how is this problem dealt with (if at all)
in that language?
a) by standardizing INCLUDE in a manner that is likely to be compatible
with how many (but not all) existing programs use it.
b) by offering new facilities such as MODULEs that, supposedly, make INCLUDE
itself "never" necessary, though I'm always suspicious of such claims, and
am glad they at least standardized existing practice (INCLUDE) while they
created new facilities (MODULE).
--
James Craig Burley, Software Craftsperson burley@ai.mit.edujlg@lanl.gov (Jim Giles) (01/08/91)
From article <1991Jan7.131620.27789@msuinfo.cl.msu.edu>, by fox@DASHER.NSCL.MSU.EDU: > [...] > .. and since INCLUDE is not part of the FORTRAN-77 standard, there's no > portable way to get the effect of a global parameter statement. [...] Well, write your INCLUDE preprocessor in Fortran 77 (a simple task) and the capability will be present on every machine that Fortran 77 runs on. There are 'off the shelf' preprocessors written in Fortran 77 listed in many books. > [...] A question > to those following FORTRAN-9x.. how is this problem dealt with (if at all) > in that language? Fortran Extended (the most recent, and let's hope final name) has both INCLUDE and MODULE in it. Either one will support global named constants (parameters). MODULES also support private constants, variables, and procedures (so a library can have internal structure that cannot be interfered with from outside). MODULEs are among the few things that the new standard does well. INCLUDE is basically redundant when MODULEs are available. J. Giles
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (01/08/91)
In article <1991Jan7.131620.27789@msuinfo.cl.msu.edu> fox@DASHER.NSCL.MSU.EDU writes:
.. and since INCLUDE is not part of the FORTRAN-77 standard, there's no
If memory serves, INCLUDE is part of MIL-STD 1753. As others have
aptly pointed out, it can easily be provided externally (cpp, m4,
trival and non-trivial homebrew processors).
The f90 solutions have already been mentioned.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043wsb@boise.Eng.Sun.COM (Walt Brainerd) (01/08/91)
In article <10553@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > > Fortran Extended (the most recent, and let's hope final name) ... > [ ... nice comments about INCLUDE and MODULES ... ] I really hope not. Most of the world has agreed to call it "Fortran 90". It has been the official name for at least a couple of years. It is the name by which the ISO standard will be known. "Fortran Extended" is an invention of X3 and only confuses everyone into thinking that perhaps it is something different from Fortran 90. Most of those working in the standards process still believe that the ISO and ANSI standards will be the same, so there is no reason for different names. Please, let's all call it "Fortran 90". -- Walt Brainerd Sun Microsystems, Inc. wsb@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991
fox@DASHER.NSCL.MSU.EDU (01/08/91)
In article <16609@cs.utexas.edu>, ubiquity@cs.utexas.edu (Richard Hoffman) writes... >In article <1991Jan7.131620.27789@msuinfo.cl.msu.edu> fox@DASHER.NSCL.MSU.EDU >writes: >>.. and since INCLUDE is not part of the FORTRAN-77 standard, there's no >>portable way to get the effect of a global parameter statement. > >One way to get a semi-portable INCLUDE *anywhere* is to use the C >preprocessor. You don't have to know anything about C, except >for the rules of #include itself. C is widely available, so most >installations will have it. I have frequently used it with FORTRAN, >and also the C #define statements, which I find much more convenient >than PARAMETER statements. > >It does add an extra step to program preparation, though. Not all C compilers decouple the preprocessor from the compiler. This implies that it's not always possible to get C preprocessor output. So this isn't so portable after all. This statement covers a few DOS compilers, and the VMS C compiler as well. Of course writing a pre-processor which understands the #include directive is not so hard, and that's probably the only *truly* portable way to do it until FORTRAN-9x compilers begin to appear. Ron Ron Fox | FOX@MSUNSCL.BITNET | Where the name NSCL | FOX@CYCVAX.NSCL.MSU.EDU | goes on before Michigan State University | MSUHEP::CYCVAX::FOX | the quality East Lansing, MI 48824-1321 | | goes in. USA
bleikamp@convex.com (Richard Bleikamp) (01/08/91)
In article <10553@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > >Fortran Extended (the most recent, and let's hope final name) has both >INCLUDE and MODULE in it. .... > (discussion of MODULEs deleted) > ..... INCLUDE is basically redundant when MODULEs >are available. > There are two very good reasons for including :) INCLUDE in Fortran Extended. 1) Its a VERY common existing practice. One of X3J3's purposes in life is to standard existing practice. 2) MODULEs, although a powerful tool for "local" software development, are not well suited for supporting 3rd party applications. For purposes of this discussion, let us assume one important use of MODULEs and INCLUDE will be the specification of interfaces to a library, and definition of some new types. Both MODULEs and INCLUDE provide this capability. The use of modules to implement a 3rd party library essentially requires the 3rd party to ship source code. Not all 3rd party vendors want to do this. It is likely that compiler vendors will compile a MODULE into some intermediate representation, which could afford some protection to the 3rd party vendor who wishes to keep their source code secret; however, intermediate representations for MODULEs are very likely to suffer from rev-lock problems with each release of the compiler. 3rd party vendors (and computer manufacturers) can't release a new copy of each 3rd party library whenever the compiler is updated. Also, INCLUDE files are more portable across different machines, while intermediate representations of MODULEs will not be portable. Public domain libraries, or GNU like licensed libraries, are good candidates for the use of MODULEs. The creator of the source code must be willing to release the source to make effective use of MODULEs. In summary, MODULEs and INCLUDE each have their own uses. Neither is likely to be replaced by the other. -- ------------------------------------------------------------------------------ Rich Bleikamp bleikamp@convex.com Convex Computer Corporation
maine@elxsi.dfrf.nasa.gov (Richard Maine) (01/09/91)
On 8 Jan 91 14:37:47 GMT, bleikamp@convex.com (Richard Bleikamp) said: Richard> There are two very good reasons for including :) INCLUDE in Richard> Fortran Extended. Richard> 1) Its a VERY common existing practice. One of X3J3's Richard> purposes in life is to standard existing practice. No argument from me here. I'm glad to see INCLUDE standardized in F90. Richard> The use of modules to implement a 3rd party library Richard> essentially requires the 3rd party to ship source code. It's not clear to me that this is so. Why couldn't source code be shipped only for the interface to the module, without shipping source code for the implementation? There should be little objection to source code for the interface. That's essentially documentation and is also pretty simillar in content to what would be shipped with include files. One of the uses for the F90 INTERFACE block (whether in a module or not) is to allow the interface to be compiled independently of the subroutine bodies. This may not meet every need, but would seem to cover the basics. I suppose it's possible for a compiler implementation to make this awkward, but it doesn't seem inherent in the concept. That's a quality of implementation issue. A bad enough compiler implementation can make almost anything awkward. See for instance, er, ah, well, hmm, no need to start a flame war here. Its a friendly discussion so far. :-) Richard> In summary, MODULEs and INCLUDE each have their own uses. Richard> Neither is likely to be replaced by the other. I'd agree here. Its even reasonable to use them together. I've got one F90 module I'm working on that is getting a little longer than I like to maintain in one source file, but does not convieniently break down into sub-modules (anyway, I threw out all my preliminary attempts to do so as too awkward). I'm may well divide the module into a few include files for no reason more esoteric than to keep the individual file sizes down. There are some logical functional divisions on which to base the splitting; it's just that enough is shared between the parts that they don't split well into separate modules. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.64.6]
lamson@el1.crd.ge.com (scott h lamson) (01/09/91)
>From: bleikamp@convex.com (Richard Bleikamp) >2) MODULEs, although a powerful tool for "local" software development, are not > well suited for supporting 3rd party applications. If third party vendors don't want to ship module source code, why should they ship include source code? modules can contain definitions and interfaces to the procedures without containing the procedures themselves. this provides all the proprietary protection that includes offer. > Also, INCLUDE files are more portable across different machines, while > intermediate representations of MODULEs will not be portable. what advantage is portable include files when the "libraries" are not portable anyway? -- Scott| ARPA: lamson@crd.ge.com Lamson| UUCP: uunet!crd.ge.com!lamson (518)387-5795| UUCP: uunet!sierra.crd.ge.com!lamson General Electric Corporate Research and Development
jlg@lanl.gov (Jim Giles) (01/09/91)
From article <1991Jan08.143747.16553@convex.com>, by bleikamp@convex.com (Richard Bleikamp): > [...] For purposes of this > discussion, let us assume one important use of MODULEs and INCLUDE will be > the specification of interfaces to a library, and definition of some new > types. Both MODULEs and INCLUDE provide this capability. > > The use of modules to implement a 3rd party library essentially requires the > 3rd party to ship source code. [...] Not true. The proposed standard itself contains an example of how to do this. The interface specifications can be placed in a _different_ module than the code it specifies. Only the source for the _interfaces_ need be shipped. The _code_ can be shipped in binary form. > [...] > It is likely that compiler vendors will compile a MODULE into some > intermediate representation, which could afford some protection to the > 3rd party vendor who wishes to keep their source code secret; however, > intermediate representations for MODULEs are very likely to suffer from > rev-lock problems with each release of the compiler. 3rd party vendors > (and computer manufacturers) can't release a new copy of each 3rd party > library whenever the compiler is updated. This is obviously an alternative to shipping the interfaces in a separate MODULE. The "rev-lock" problem (if it exists at all) will be no worse than it is now. After all, if the vendor wants to keep his source private _now_, he ships binary - which is also subject to needing revision when the compiler changes. In fact, there is no reason that the intermediate form of a MODULE need differ _at_all_ from binary for that module. The binary already needs to contain relocation information, debugging information (as some form of symbol table), etc.. It might as well _also_ contain any MODULE specific information. > [...] > Also, INCLUDE files are more portable across different machines, while > intermediate representations of MODULEs will not be portable. Again, if the vendor is trying to keep his source secret, he's shipping binaries anyway. What good does it do him to have portable interface specifications if the code itself isn't portable? Or, are you claiming that binaries _are_ portable in some context where the intermediate representations are not? Further, INCLUDE is not _really_ all that reliably portable. Read the Fortran Extended document some time. The INCLUDE feature is so vaguely defined that a standard conforming compiler can do pretty much what it likes with them - including ignoring them entirely. You may not like MODULES for some purposes, but at least they are well defined in the proposed new standard. I agree with you that _if_ INCLUDE were well defined, there would be some things that it would be better at than MODULE. However, that is _not_ the case in the current proposed standard. J. Giles
bleikamp@convex.com (Richard Bleikamp) (01/09/91)
In article <MAINE.91Jan8083424@altair.dfrf.nasa.gov> maine@elxsi.dfrf.nasa.gov (Richard Maine) writes: >Richard> The use of modules to implement a 3rd party library >Richard> essentially requires the 3rd party to ship source code. > >It's not clear to me that this is so. Why couldn't source code be shipped >only for the interface to the module, without shipping source code for >the implementation? There should be little objection to source code >for the interface. That's essentially documentation and is also pretty >simillar in content to what would be shipped with include files. > you're right. I didn't explain my point very well. What you suggest works ok. It just doesn't buy you very much thay INCLUDE doesn't. In particular, you are giving up optional and keyword arguments when only the interfaces are contained in a module. The one obvious advantage gained is that MODULE names are standardized while INCLUDE objects are not. The 3rd party vendor; however, can more easily document how to use INCLUDE (all UNIX systems will be the same). Using MODULEs will be less consistent across vendors, and more difficult to document for the third party vendor. -- ------------------------------------------------------------------------------ Rich Bleikamp bleikamp@convex.com Convex Computer Corporation
jlg@lanl.gov (Jim Giles) (01/09/91)
From article <1991Jan08.202010.3056@convex.com>, by bleikamp@convex.com (Richard Bleikamp): > [...] > 1) When you only include the INTERFACEs and global data for an external > library in a module, you have lost almost all the benefit of using > a module. [...] No one suggested this. The interface specifications and global data are in one MODULE, the code is in another - call them the interface and the implementation MODULEs. The implementation MODULE can still contain both type definitions and the procedures that operate on those types: this is the _main_ benefit of using MODULEs (encapsulation). The implementation MODULE can still contain PRIVATE data and procedures: this is the second most important benefit of MODULEs. Way down the list somewhere is the ability to keep the interface specifications with the code it refers to. This is the _only_ benefit you lose by separating the interface into a different MODULE. And, you can still do this, provided you don't mind distributing the whole source. > [...] INCLUDE provides the same capability. Which is what I said to start off this line of discussion. The word "same" denotes an equivalence relation. Equivalence relations are symmetric (a=b implies b=a). You say that INCLUDE provides the same capability. I began this thread by saying that MODULEs provide the same capability. > [...] > 2) It is believed to be true that one module can contain the INTERFACEs > and global data definitions for a package, and another different > module can contain the source code for the routines. This was > discussed at one the fortran 90 implementation symposiums, and > we could not agree on whether two or three modules were required to > achieve the desired result. [...] I don't understand why three would be _required_. The only thing that requires even _two_ is the vendor constraint against distributing source. > [...] This is at best convoluted, and unlikely > to actually work in the early Fortran 90 compilers. [...] Condemning a feature because of the possibility that the compiler won't work can be applied to _all_ new features (and all old ones for that matter). I didn't find the definition of MODULEs all that difficult to grasp. Certainly, I think it's more likely to work on the early compilers that KIND= stuff, or the POINTER attribute, or whole array operations, etc.. But then, maybe I'm missing something. Would you care to elaborate about the kind of problems you anticipate (including why you thought three separate modules might be needed)? > [...] Usually, procedure > call mechanisms, and access to COMMON is not changed from one release to > the next. For MODULEs though, it is likely that some compiler data structures > (such as symbol tables) will be contained in the intermediate representation > of a pre-compiled MODULE. This is almost certainly going to cause rev-lock > problems. I don't understand. The symbol table information should be contained in _all_ binaries - not just MODULEs. In fact, it should be transcribed into the executable by the loader. Otherwise, symbolic debugging is not possible. I realize that symbolic debugging on many small systems is not yet the norm, but in professional quality environments it's essential. In what important ways does a MODULE intermediate form differ from (say) a C dot-oh file? Both should contain symbol table info (as above). Both should contain relocation info (obviously). Both should contain interface info (yes, even the C version - how else can the linker actually verify that a procedure really matches the function prototype that the calling routine claims? What!?!? Your C environment doesn't do this? How can you call yourselves ANSI C conforming? :-). Both must contain lists of all the globals that they use (that's part of the relocation information). Both must contain lists of all the globals they declare (also part of the relocation information). The both should even contain descriptions of user defined types (derived types in Fortran, unions and structs in C) - this info should be in a language independent form in the symbol table. Well, with all this info available, the Fortran compiler should just learn to read binaries and it can get all the MODULE info it needs - so forget about even having to split off the interface stuff into a different MODULE, this should do it all. To be perfectly honest, the only thing listed in the previous paragraph that isn't routinely present in the object code (in a language- independent form no less) on most production quality systems is the interface information. As I pointed out, even this info _should_ be present. If it isn't, that's when you'll have to split the interface specifications out of the implementation MODULE. Whether you put the interfaces into another MODULE of into an INCLUDE file _should_ be an arbitrary decision. J. Giles
corbett@road.Eng.Sun.COM (Robert Corbett) (01/09/91)
In article <10652@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Further, INCLUDE is not _really_ all that reliably portable. Read the >Fortran Extended document some time. The INCLUDE feature is so vaguely >defined that a standard conforming compiler can do pretty much what it >likes with them - including ignoring them entirely. You may not like >MODULES for some purposes, but at least they are well defined in the >proposed new standard. I agree with you that _if_ INCLUDE were well >defined, there would be some things that it would be better at than >MODULE. However, that is _not_ the case in the current proposed >standard. > >J. Giles You have got to be kidding. The specification of MODULEs in Fortran Extended leaves so much up to the implementor that there are liable to be dozens of incompatible implementations (assuming there are dozens of implementations). There is nothing in the standard that requires an implementor to allow a MODULE to be referenced in a file other than the one in which it is defined. As Section C.11.3 states, The exact meaning of the requirement that the public portions of a module be available at the time of reference is processor defined. I complained about the need for tighter requirements on the rules for MODULEs in the first two public reviews and was told that it is a quality of implementation issue. It is now, but it need not have been. Yours truly, Bob Corbett
gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) (01/09/91)
In article <5428@exodus.Eng.Sun.COM> wsb@boise.Eng.Sun.COM (Walt Brainerd) writes: >In article <10553@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: >> >> Fortran Extended (the most recent, and let's hope final name) ... >> [ ... nice comments about INCLUDE and MODULES ... ] > >I really hope not. Most of the world has agreed to call it "Fortran 90". >... >Please, let's all call it "Fortran 90". I prefer "Fortran 90" for a different reason... Fortran 77 was introduced well over a decade ago, yet an alarming percentage of code dates back to 60's style. At least two reasons for this were the limits of ANSI 77 and the wide gap between vendor specific compilers (VAX extended for example) and the ANSI standard. Useful structured syntax such as DO WHILE and END DO were 'left out` of the strict standard to be absorbed into the chaotic realm of dozens of 'roll your own extensions'. The result was (is) unnecessary language porting problems over the past decade. Lest we let history repeat itself, get the necessary 'extensions' into the 'standard', call it Fortran XX and get on with it!!!!! -- John L. Bradberry |Georgia Tech Research Inst|001100110011001100110011 Scientific Concepts Inc. |Microwaves and Antenna Lab|Int : gt4512c@prism 2359 Windy Hill Rd. 201-J|404 528-5325 (GTRI) |GTRI:jbrad@msd.gatech. Marietta, Ga. 30067 |404 438-4181 (SCI) |'...is this thing on..?'