Comment by Daniel Grimwood

To:	J3

From:	Craig Dedo

Date:	November 11, 2002

Subject:	Comment by Daniel Grimwood

ISO/IEC JTC1/SC22/WG5 N1499

Comment on Fortran 2000 CD from Australia

Draft Australian/New Zealand Standard Comment Form

Section 1 - Draft Details

To: ISO/IEC JTC 1/SC 22

Mr/Mrs/Ms: Mr

First Name: Daniel

Last Name: Grimwood

Position Title: Research Officer

Organization Details: Department of Chemistry

The University of Western Australia

Street Number and Name: 35 Stirling Highway

Suburb: Crawley

State: WA

Postcode: 6009

Contact Details:

Email : reaper@theochem.uwa.edu.au

Phone : +61 8 93803138

Fax : +61 8 93801005

Subject Title: Fortran 2000 (ISO/IEC 1539-1) draft

Date of Comment: 31/10/2002

Section 2 - Comments

1. C.8.2.1

Lines 18-22

It is difficult to write makefiles and scripts that work with module

information files, since although vendors base their naming schemes on

the name of the modules, some convert the names to uppercase/lowercase,

and different vendors use different file extensions. Modern

file systems distinguish between upper and lower case, so it is

important that the mapping from Fortran to file system is standardized

for such cases. It is recommended that this either be the name of the

module converted to lower case or upper case, or be the name of the

module exactly how it is declared. Most but not all vendors give the

files a .mod suffix, so it would be trivial to standardize this aspect

of the file name.

The proposed change is to append an extra sentence to the paragraph, such as:

If permitted by the file system, the file should be named as the

lowercase name of the module with a .mod suffix appended.

Under the proposed change, module "ThIsModULE" produces the file called

"thismodule.mod".

J3 Response: This is outside the scope of the Fortran standard. See section 1.4.

2. C.8.2.1

Lines 23-28

In this paragraph a choice is given as to whether a module information

file should contain all information about a module, or include pointers

back to other files that contain some of the information. It appears

that all vendors have chosen the route of putting all information into

the file and to not use file pointers. Thus it would be minimal

inconvenience to remove the choice and force vendors to not use

pointers to other files. The benefit is that currently, for the method

of using file pointers, it is near impossible to write automated

dependency generators that use the "USE" statements of modules, since

the file pointers mean that there are implicit dependencies that are

not evident in the currently processed module. If there are no file

pointers, then the dependencies become trivial.

Delete the paragraph and replace with:

The result of translating a module must contain all public

information specified in the module (including copies of public

information originally specified in other modules).

J3 Response: This is outside the scope of the Fortran standard. See section 1.4.

3. C.8.2.2

Line 15

The last sentence acknowledges that if the public attributes to a

module do not change, then other modules that use that module should

not need to be recompiled. Unfortunately, some vendors insert the

compilation date into translated modules, and this may be the only

difference between two translations of the same module (even if no

public or private attributes have changed). This unnecessarily reduces

the ability to avoid recompiling other modules that use that module.

Add the following sentence to the end of the paragraph:

If neither the public or private attributes differ between two

versions of a module, then the results of translating the two

versions should be identical.

J3 Response: This is outside the scope of the Fortran standard. See section 1.4.

4. 5.2.1

Page 84, Line 22

This comment is not backward-compatible with previous Fortran

standards, but it is better to fix this in the Fortran 2000 standard

than to leave it broken indefinitely.

Having a default accessibility of "public" for modules means that, by

default, as more modules that USE each other are added to a chain of

such modules, the name space of publicly available entities becomes

larger and the time/space taken to compile the last modules of the

chain becomes unacceptably large. This problem grows indefinitely,

until the programmer overrides this default with a "private"

statement. This is a simple solution, but most new users to Fortran

would be unaware of it. Furthermore, it is difficult for newcomers to

debug conflicting names of entities when no such entities are present

in modules they have explicitly USEd, but rather are defined in

implicitly USEd modules. It would be better to adopt the philosophy

that if you want to propagate an entity between modules, then do so

manually, and if you want to use an entity in another module, then USE

that module explicitly.

Change the phrase "the default is public" to "the default is private".

J3 Response: This change is incompatible with the current Fortran standard.

References

02-007r3, Fortran 2000 Committee Draft

[End of J3 / 02-322r1]