 |
 |
Hi, On Wed, 12 Jun 2002, Van Snyder ([log in to unmask]) wrote: > I did, and complained several times, both during the latter stages of > development and during public comment. I was not serving on X3J3 at the > time, so I cannot speculate why the problem was not corrected before > Fortran 90 was published. I'm glad I'm not the only one frustrated by all of this. At the moment I'm optimising PRIVATE routines of a particular module. This module only takes a minute to compile, but the one that USEs it takes about ten minutes to compile. Linking takes about a minute. The test job that I run to make sure I haven't stuffed up (eg, typos) takes only 25 seconds to run. Avoiding the cascade is a *big* issue for me :). > It has now been realized that there are problems, and a Type-II Technical > Report has been authorized to address the deficiencies. The subject of > the report is to allow expressing a module as an "interface" part and > zero or more "implementation" parts, as is done in Modula-2 (only one > implementation part) and Ada (multiple implementation parts by way of > "library subunits"). The "interface" part will be compatible with > Fortran 2000 modules. I.e., you can put everything there, and have no > "implementation" parts. The "implementation" parts for a single module > will depend on its "interface" part, not vice-versa, and perhaps on each > other. Nothing else can depend on them, so you can change a detail of an > "implementation" part of a module, and not get a compilation cascade. > More importantly, if your software engineering protocol requires > re-certification of every program unit that gets re-compiled, you don't > get a re-certification cascade, which could be far more expensive than a > compilation cascade. I really like the sound of this. I don't mind additional files generated by the compiler hanging around that contain "implementation" stuff if they need it, but it would be great to *require* .mod files contain only "interface" stuff. It wouldn't fully address the problems of having files up to date (still have to use timestamp files, recursive Make, checksums, or ...), but it would absolutely minimise the cascade and make our silly "cmp" scripts redundant. > A Type-II Technical Report has nearly the stature of a standard. The > agreement is that it will be incorporated into the next standard > exactly as specified, unless substantial implementation problems or usage > problems are discovered. There have already been two Type-II Technical > Reports that amend Fortran 95. Many vendors have implemented them, and > they are being incorporated into the Fortran 2000 standard. > The plan is that the technical report on module facilities will be > published at about the same time as the standard. Will the report be published separately? It would be great to have part of it in section C.8.2 of the standard, i.e., say that module information files contain interface information only. While we're at it, I think a slight modification to C.8.2.1 of the standard would go a long way to universal makefiles/scripts. For example, in regard to module information files, "Thus the processor may have to provide a mapping between Fortran name and system names" is a bit vague, as there's nothing about file extensions or uppercase/lowercase. Whilst MS-DOS can't handle names more than 8 characters long, it seems that all(?) O/S's can handle a .mod suffix, so it would not be difficult to force the generation of a .mod file with interface-only information. Likewise, most Unices can handle uppercase and lowercase, yet the vendors are split down the middle as to who uses uppercase and who uses lowercase. MS-DOS has it's limits, but does this have to translate into ambiguity for the rest? (Note that just because a compiler is forced to generate a certain file doesn't necessarily mean it has to use that file, so compilers don't need to be rewritten to achieve this.). Section C.8.2.1 also mentions that .mod files that propogate PUBLIC information may have pointers to other .mod files rather than just copying the PUBLIC information into their own .mod files. I don't think that any vendors use these pointers, so now is a good time to get rid of the suggestion. Such a method makes a meal out of the avoidance of cascading recompilation, because not only do you have to examine the modules that you USE, but also the ones that they USE, and so on. But of course this is only true for PUBLIC information, not PRIVATE information, so your dependency generator would have to keep track of PUBLIC and PRIVATE entities in all prerequisites. Aargh! Let's get rid of it, and make "including copies of information originally specified in other modules" the only option. F2k is a good opportunity to fix up modules, and this interface-only requirement sounds like a good idea. I hope we can fix up these other smaller problems too. Regards, Daniel. -------------------------------------------------------------------------- Daniel Grimwood Department of Chemistry Email : [log in to unmask] The University of Western Australia Phone : +61 8 93803138 35 Stirling Highway Fax : +61 8 93801005 Crawley WA 6009