ISO/IEC JTC1/SC22/WG5 N1530

	               
             Keep Environment Procedures as Intrinsics
                    
                         Craig Dedo


In sections 2 and 3 of his paper 'ISO_FORTRAN_ENV', Richard Maine argues 
that the procedures that are new to Fortran 2000 should be part of the 
ISO_FORTRAN_ENV module rather than intrinsic procedures. These include: 
COMMAND_ARGUMENT_COUNT, GET_COMMAND, GET_COMMAND_ARGUMENT, 
GET_ENVIRONMENT_VARIABLE, IS_IOSTAT_END, IS_IOSTAT_EOR, and NEW_LINE. 
According to his paper, Richard believes that they should be part of the 
module because they 'concern system-dependent aspects of the Fortran ... 
environment'.


I disagree. I believe that all of them should be kept as intrinsic 
procedures.


The main reason is my philosophy of language design. I believe that it 
is better language design to make all Fortran standard procedures 
intrinsic unless there is compelling reason to place them into a module. 
This simplifies the user interface. Intrinsic procedures are there 
automatically; the application developer does not need to engage in any 
explicit action in order to have them available for use.


This is in sharp contrast to C and its derivatives. With those 
languages, in order to get any procedure, you have to #include the 
correct header file. Thus, the programmer is always having to remember 
which of two dozen header files contain the definitions for which 
procedures. E.g., 'If I want tolower() or toupper(), I have to #include 
<ctype.h>, but if I want memchr() I have to #include <string.h>.'


Remembering such classifications is a major headache and the potential 
for a significant loss of human productivity. I have done C programming 
in commercial firms with profit and loss responsibility and real money 
at stake. In some of these firms, it was standard development practice 
to #include all of the header files defined in the C standard in order 
to avoid forgetting to reference the proper header file. This was done 
precisely to avoid these kinds of inefficiencies.


One of the original design goals of Fortran was that it would be easy to 
use for the non-expert. I believe that we should continue to adhere to 
this design goal as much as circumstances permit.


I believe that ease of use for the application developer is a far more 
important decision making criterion than elegance of formal 
classifications within the standard.


Richard Maine mentions that there already are procedures defined within 
the IEEE_* and ISO_C_BINDING modules. That is true, but in these cases 
there are compelling reasons to provide these intrinsic modules and to 
place the procedures in these categories in their respective modules.


1. Both the IEEE exception handling and C interoperability features 
require the definition of many named constants that have values that are 
characteristic of the Fortran processor or companion processor. Fortran 
does not have reserved names, so the most practical method of providing 
these named constants is to define them inside of an intrinsic module.


2. The IEEE exception handling feature can seriously degrade execution 
efficiency on some processors, so it is highly desirable so provide the 
application developer a means of using the feature only when necessary 
and turning it off when it is not needed.


3. The C interoperability feature has the possibility of interoperating 
with more than one companion processor. Thus, the application developer 
has to have some means of specifying which companion processor is used 
and referencing the correct set of definitions.