cdb@hpclcdb.HP.COM (Carl Burch) (03/09/88)
> 3) MODULE would inhibit independent compilation -- a BIG no-no in my world.
You might note that INCLUDE is also dependent compilation - it's just
uncheckable dependent compilation. With MODULEs, the revision date can
be checked by the compiler between the source and the preprocessed module
to ensure that your compilation is consistent.
As for X3J3 only standardizing "existing practice", that's equivalent to
saying that only vendors should be allowed to do language design. One of
the reasons that the draft standard is so ambitious is that many users
were disappointed with the generally conservative '77 standard (produced by a
committee composed largely of vendors) and joined the committee with the
general intent of getting a modernization of Fortran that their vendors
seemed unwilling to give them. As I work for a vendor on the compiler team,
I get my say in the process either way - but I wonder if those that are
expounding that point of view really think that their vendors always know
best <commercial ommitted here :-) > ?
Carl Burch
HP Fortran Team
Usual disclaimer - HP expresses its degree of
agreement with my views only on payday.jlg@a.UUCP (Jim Giles) (03/11/88)
In article <6690013@hpclcdb.HP.COM>, cdb@hpclcdb.HP.COM (Carl Burch) writes: > > 3) MODULE would inhibit independent compilation -- a BIG no-no in my world. > > You might note that INCLUDE is also dependent compilation - it's just > uncheckable dependent compilation. With MODULEs, the revision date can > be checked by the compiler between the source and the preprocessed module > to ensure that your compilation is consistent. Checking the revision date at compile time doesn't help. Two seperate routines might both use the module, but the routines might be compiled seperately! The loader is the only tool that can check the consistency of use. Also, a checksum is better than a revision date. Modules are involved with another inhibition of independent compilation. Section 11.3.3.3. A derived data type may be defined in a module and accessed in a number of program units. This is the only way to access the same type definition in more than one program unit. But this isn't really the fault of modules. The committee should have allowed different program units to independently define a derived data type. Other than the above rule, modules do not inhibit seperate compilation any more than include files do. If you support include files, you obviously oppose the rule in 11.3.3.3 already. So, support for include files eliminates seperate compilation as a valid objection to modules. J. Giles Los Alamos