From LPMeissner@msn.com Wed Dec 4 03:52:55 1996 Received: from upsmot03.msn.com (upsmot03.msn.com [204.95.110.85]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id DAA04682 for ; Wed, 4 Dec 1996 03:52:53 +0100 Received: from upmajb06 ([204.95.110.89]) by upsmot03.msn.com (8.6.8.1/Configuration 4) with SMTP id SAA27539 for ; Tue, 3 Dec 1996 18:51:32 -0800 Date: Wed, 4 Dec 96 00:27:06 UT From: "Loren Meissner" Message-Id: To: sc22wg5@dkuug.dk Subject: Proposed Industrial Strength Standard Fortran Subset WHITE PAPER by Loren Meissner, 3 December 1996 Objectives: - Get rid of deprecated features with a "fresh start" instead of incrementally - Enforce the safety features that are optional in F90 and F95 - Do not put unnecessary roadblocks in the way of conversion from full standard Fortran to the Subset language This proposal proceeds downward from the full Fortran language, not upward from the existing subsets (Elf90 and F). However, the development of any such proposal should draw on experience gained with existing subsets. [This proposal has been read (in an earlier version) by one other person, who more or less agreed with it.] "Subset Fortran" MUST ALWAYS BE A TRUE SUBSET of whatever standard full Fortran language is out there, at least for 20 years or so. If a Subset Fortran like this one ever catches on, maybe later this constraint can be dropped, but if so, some comprehensive version of the language should probably remain forever as an "archival standard." 1. Remove storage association. This includes COMMON, EQUIVALENCE, and argument (array/string) sequence association. This is obviously the "biggie". No subset that retains storage association is worth the effort. On the other hand, removing storage association will cause a lot of work for people who want to convert full-language programs to Subset Fortran. There are already some tools to help with this, but a standard Subset Fortran would no doubt give an incentive for more of them. (LOFT from NASoftware and VAST from Pacific-Sierra give experience with converting COMMON blocks to modules - not too hard if the storage sequences agree, and difficult but not always impossible if they don't agree. Some of the ways people use EQUIVALENCE are probably impossible to convert automatically.) Without storage association, there is no longer any need for the SEQUENCE derived type attribute. But the "standard array element sequence" is still needed for whole-array I/O etc. 2. Remove all implicit interfaces. This is the next biggest trap for the unwary. Many of the same arguments as above apply, but unsafe procedure interfaces probably appear less often and are easier to find (although probably still not easy to automatically replace with "good" alternatives.) I hate to say this, BUT I guess it would be OK to keep external subprograms, for inter-language operability. (People have been pointing out that an explicit interface to an external is never checked, even though it tends to fool you into thinking that it is. So everyone must learn to avoid externals wherever possible.) 3. Require explicit declaration of all variables. But, do not require the IMPLICIT NONE statement. (I am assuming that hardly anybody will want to move Subset Fortran programs to full language platforms - which is not the same as for existing subsets.) ========================================================================= At this point, you the most important safety features PERMITTED by F90 and F95 are REQUIRED by Subset Fortran. 4. Remove fixed source form, of course. Remove double precision except as a real/complex KIND. Remove attribute-oriented declarations. 5. Remove NAMELIST and INCLUDE (controversial?). 6. (Less obvious:) Require function RESULT clause with type declared inside; require INTENT for all dummy args. (Some F/Elf experience may help here: Both subsets have these restrictions, and they don't seem to hurt anyone.) 7. Maintain current Fortran rules about case insensitivity and no reserved words. 8. Specify some things that are processor-dependent in the full language: for example, require support for ASCII as at least one char kind (maybe even require it as the default for program text etc.) 9. Remove anything else on all of the decremental/obsolescent lists that I have forgotten to mention.