From owner-sc22wg5@dkuug.dk Wed May 7 00:46:35 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h46MkZr6015753 for sc22wg5-domo; Wed, 7 May 2003 00:46:35 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from out2.mx.nwbl.wi.voyager.net (out2.mx.nwbl.wi.voyager.net [169.207.3.120]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h46Mk9Ec015745 for ; Wed, 7 May 2003 00:46:32 +0200 (CEST) (envelope-from Craig_Dedo@execpc.com) Received: from execpc.com (d86.as3.nwbl1.wi.voyager.net [169.207.85.214]) by out2.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id D7CD1293F7 for ; Tue, 6 May 2003 17:46:57 -0500 (CDT) Message-ID: <3EB83B76.8060005@execpc.com> Date: Tue, 06 May 2003 17:47:18 -0500 From: Craig Dedo Reply-To: Craig Dedo Organization: Elmbrook Computer Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (nscd2) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WG5 Mailing List Subject: Keep Environment Procedures as Intrinsics Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Dear WG5 Members: I am offering this paper as a rebuttal to sections 2 and 3 of Richard Maine's paper on the ISO_FORTRAN_ENV module. Please feel free to discuss this rebuttal and send me any questions, concerns, or comments that you may have. To: WG5 From: Craig Dedo Date: May 6, 2003 Subject: Keep Environment Procedures as Intrinsics 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 , but if I want memchr() I have to #include . 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. -- Sincerely, Craig T. Dedo 17130 W. Burleigh Place E-mail: Craig_Dedo@execpc.com Brookfield, WI 53005-2759 Voice Phone: (262) 783-5869 USA Fax Phone: (262) 783-5928 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin (1759)