X3J3/96-168 Date: November 12, 1996 To: X3J3 From: Christian Weber Subject: Miscellaneous Requirements for Fortran 2000 16th Oct. 1996 Dear Fortran Colleagues, I have now finished the collection of requirements which may be considered as "miscellaneous", and I have described these in the attached document "Miscellaneous requirements for Fortran2000" (version 1); this document also reflects the email comments which I have received so far. Would you please review the document concerning - completeness of the list (are any requirements missing?), and - the classification (which I have done out of my personal judgment) concerning the work caused to X3J3 by the requirement (which essentially also yields the identification as "minor technical enhancement"). Could you furthermore give additional information (technical information, example F95 extensions, items to be discussed etc.) concerning these requirements as input to the second version of the attached document which I plan to prepare by december 10th (so please send in your comments by end of november). Together with the distribution of the second version of the document I would like to start an "opinion poll" about the priority of these requirements which will last until December 24th, such that I have enough time left to incorporate the results into the final version of the document (which has to be ready in time for the Las Vegas meeting). I would suggest (much according to Gerhard Schmitt's suggestions) to proceed with this opinion poll as follows: - every member of this subgroup gives an opinion if he is *opposed* to a particular requirement regardless of the work caused by it (this part of the opinion poll also includes minor technical enhancements, and if there is strong and/or unanimous opposition to a particular requirement it should be removed altogether from the requirements list); - furthermore, every member of this subgroup has - say - 20 "priority points" which he can distribute to the *major* (i.e. the non-minor technical enhancements) requirements with a maximum of 3 points per individual item (this limit shall prevent that requirements which are wanted very strongly by only one individual may get too much weight). It could be debated if requirements causing a "large" amount of work shall cost more priority points than "medium" requirements. Regards Christian Weber ============================================================== Christian Weber Siemens Nixdorf BS2000 SA Otto-Hahn-Ring 6 81739 Munich / Germany e-mail: christian.weber@s31.mch1.x400scn.sni.de Tel.: +49 89 636 49240 Fax: +49 89 636 41776 ============================================================== Miscellaneous Requirements for Fortran2000 ============================================ (Christian Weber, 16th Oct. 1996, Version 1) 1. Introduction --------------- To facilitate the discussion of requirements for Fortran2000, this documents collects all requirements which may be considered as miscellaneous, i.e. which are - neither concerned with better data or interface abstraction, - nor concerned with aspects of high-performance numerical computing, since such requirements are handled by the other subgroups. Furthermore, this document does not deal with requirements which are already handled by a dedicated activity (e.g. some TR, such as the IEEE TR), or which aim at an improvement of the standards process or standards document itself: Such requirements have to observed by the developmend body directly at all activities - they cannot be compared with "technical" requirements within the same list. For all the miscellaneous requirements this document does not want to duplicate the information already contained in the requirement repository, but rather concentrates on - adding further technical information (wherever known) especially if it may be helpful to judge how much work to X3J3 this requirement will cause, and - adding some "importance weight" (after the opinion poll) to each requirement for all major requirements (it is assumed that minor technical enhancements will be handled anyway by X3J3 at each large standard revision such as Fortran2000). In the following, the requirements are classified according to the amount of work caused to X3J3 as follows: - "small" (amount of work): the requirement is technically fairly simple, does not cause a lot of discussion, there is no principal objection to be expected (apart from the "keep the language small!" principle), and it can be covered with 1 page of edits. Such requirements may be considered as "minor technical enhancement". - "medium": fairly straighforward enhancements with 1-3 pages of edits which are concentrated essentially in one chapter of the standard. - "large": more pages with edits, and/or many places in the standards document to be updated, and/or controversial discussions to be expected. The requirements are ordered according to the document chapter(s) addressed, and the numbers in the titles refer to the entry- number in the requirements repository. Recent changes of the requirements list: As a result of the recent email comments, repository entry 72 ("Extend ALLOCATE to specify non-kind type parameters") is not considered to be miscellaneous any more, but is assigned to "data abstraction" since 72 deals with full support of derived type paramters rather than the enhancement of the executable statement ALLOCATE. Furthermore, I considered requirement 51 ("Annex of processor dependent items") to be of general nature (i.e. concerned with the standards process in general) and therefore did not incorporate it into the miscellaneous requirements list. 2. General Syntax Enhancements 2.1 Block Comments (Repository-entry 7) Subject: There should be some syntax to mark a whole "block of comments" (which spans several lines) without specifying "!" on each individual line. Rationale...: see repository. Note: This requirement might already been satisfied by the "condi tional compilation facility" (which allows to blank out large blocks of text - e.g. comments - from the compilation process). Amount of work for X3J3: small. 2.2 Lower Case Syntax Elements (67) Subject: Lower case letters should always be accepted as equivalent to upper case letters (outside character context). (Currently, the support of lower case letters - in the sense above - is only optional). Rationale...: see repository. Amount of work for X3J3: small. 2.3 Reserved words (92) Subject: The use of reserved words should be forbidden for other than their dedicated purposes (e.g. as variable names). Rationale...: see repository. Amount of work for X3J3: small. 3. Constants and Expressions 3.1 Extend Initialization of COMPLEX Variables (66) Subject: The syntax of constant expressions should allow that complex constants can be pieced together from the real and imaginary part treated separately, as e.g. by CMPLX(ANTON,DORA)) with ANTON/DORA being real named constants. Rationale...: see repository. Amount of work for X3J3: small. 3.2 Permit BOZ constants in the TRANSFER function (69) Subject: The use of binary/octal/decimal literal constants should be extended to the TRANSFER function (currently, these are only allowed in DATA statements) Rationale...: see repository. Problems: I doubt that the use of BOZ constants can reasonably be limited to a particular function (as e.g. TRANSFER); it might be extended in general, though. Amount of work for X3J3: small. 3.3 Allow MERGE in constant expressions (71) Subject: Allow some further intrinsic function reference (i.e. MERGE) in constant expressions. Rationale...: see repository. I am not fully sure what exactly is missing in Fortran95 (MERGE appears to be elemental and therefore is permitted already in constant expressions - or not?). Amount of work for X3J3: small. 3.4 New Special Character designations (77) Subject: Special characters usual in UNIX/C language (such as \n=new line, \t=tab) should be allowed in Fortran character context. Rationale...: see repository. Problems: Interaction of \n with the Fortran "end-of-record" concept? Amount of work for X3J3: medium. 4. Data Types 4.1 Bit Data Type, String (21) Subject: There should be a data type BIT (concatenable to a string as the present character data type) which actually uses one bit of storage. Rationale...: see repository. Problems: There are doubts within the DIN working group that the BIT type is really needed (alternatives: better bit intrinsics which operate on INTEGER arrays, or some LOGICAL kind which assigns one bit of storage in combination with some general "stringing" facility). Amount of work for X3J3: large. 4.2 Varying length character with declared maximum (34) Subject: Establish a PL1-like data type CHARACTER VARYING with some declared maximum (where the Fortran system handles the "current length" bookkeeping). Rationale...: see repository. Problems: This data type is a kind of competitor (within Fortran) to the string module. The fixed maximum length (necessary for a very efficient implementation) limits its usefulness. Amount of work for X3J3: large. 4.3 Unsigned INTEGER Data Type (37) Subject: Enhance the number model for integers to include unsigned numbers (0..maximum). Rationale...: Make best use of the current hardware architectures which normally do support unsigned numbers; C-Interoperability; see also repository. Problems: If C-Interoperability is the main issue, then simpler means (MAP_TO approach, some conversion intrinsic) may solve the problems. Amount of work for X3J3: medium. 4.4 Specifying Default Precisions (49) Subject: The user should be able to define the KIND value which is implicitly assigned to all floating point numbers which do not have an explicit kind specification. Rationale...: see repository. Amount of work for X3J3: medium. 5. Control Flow Constructs 5.1 Exception Handling (5,5a,5b,5c) Subject: The requirement deals with enhancements in two directions: (1) Establish some high-level control flow constructs (such as ENABLE... / SIGNAL) to define - for a certain code region - a central (user-defined) exception handling mechanism which is invoked by the processor whenever an error (of a certain kind) occurs * within the designated piece of code, or * within a subroutine which is invoked (either directly or indirectly at any calling depth) from within the designated piece of code. The control flow construct should allow * block-structured nesting of exception handling definitions, and * the signaling of user-detected exceptions at any calling depth which will cause a jump ("longjump") to the nearest appropriate exception handling block further up the calling chain. (2) Establish some mechanism to control the behaviour of the processor in certain error situations where now (normally in a processor-dependent fashion) * the program is terminated with some error message, or * the error might be ignored, resulting in wrong program results. Examples for such error situations are: * IEEE floating point exceptions if the algorithm shall be halted in case of error (note that the IEEE TR covers *only* the case of continuation with not-a- number results after exceptions), * integer arithmetic exceptions, * lack of memory, * I/O errors if no IOSTAT... parameter has been specified, * access of array elements beyond the index bounds, * access of dummy arguments which are not present, etc. Example how the requirement might be satisfied: The last version of John Reid's ENABLE proposal would essentially satisfy all the requirements. It introduced for the definition of "exception areas" a syntax like: ENABLE (condition) .... Fortran code to be controlled .... HANDLE .... Fortran code to deal with the exception .... END ENABLE For signalling a user-detected exception there was some new SIGNAL (condition) statement. Some reduced syntax (as Jerry Wagener has proposed) might be - as a first step - sufficient as well. It should be possible to discuss separately the general high- level construct (ENABLE...) and the set of error situations which have to be detected by every Fortran processor. Rationale: The reasons for exception handling (in general) are described in the repository. It has been argued that the exception handling needs are now sufficiently satisfied by the IEEE TR. This is, however, only partially true: - The IEEE deals with IEEE floating point exceptions only, and even with these only if the algorithm may be continued (with not-a-number result) in case of error. All the other exceptions (see above) cannot be handled so far. - There is no high-level construct yet to deal with exceptions at a central point, especially if the exceptions occur further down the calling chain. Therefore, the handling of exceptions which may occur in subroutines must currently be programmed as follows: * the subroutine reports any exception by some return parameter value, * at each invocation of the subroutine the caller must inquire this return value, normally just to stop the further processing in case of error and to hand back a (different) return value to its own caller. This handling is very error prone and causes the production of a lot of lines of code which are unnecessary in other programming languages (such as C++ which *does* offer an appropriate exception handling feature). Problems: (1) The routines along the call chain between the exception handling block and the "signalling" point must always be prepared for a termination by "longjump". This preparation may involve some additional calling overhead even if no exception ever occurs. Possible solutions: * accept the overhead (which is not all that large after all), * demand from the user that he marks all subroutines which should prepare to for a longjump termination with some new syntax construct (e.g. USE EXCEPTION_SUPPORT). (2) The detection of certain exceptions may be difficult to implement (e.g. INTEGER_OVERFLOW may not be supported by all hardware architectures). (3) The impact of exception handling on optimization must be carefully observed (I think, though, that John Reid's proposal has solved this problem adequately). Amount of work for X3J3: large, although a good part (most?) of the necessary work has already been done by John Reid's ENABLE proposal. 5.2 Extend the semantics of the EXIT statement (25) Subject: Enhance EXIT such that any kind of executable block construct can be left. Rationale...: see repository. Amount of work for X3J3: small. 6. Procedures 6.1 Nesting of internal procedures (33) Subject: It should be possible to define internal procedures which are local to other internal procedures. Rationale...: see repository. Amount of work for X3J3: medium (large?). 6.2 Allow internal procedures as actual arguments (42) Subject: It should be possible to pass the names of internal procedures as actual arguments. Rationale...: see repository. Problems: Since internal procedures have access to the variables in all the surrounding scoping units, it has to be defined how this access works (and has to be implemented) from an internal procedure which is called via an external procedure. Example (-> means "subroutine call"): anton -> berta (internal to anton) -> otto (external, getting berta as actual argument) -> berta (by calling the dummy-arg- procedure). Let's assume that berta accesses the variable xyz with xyz being a local (stack) variable of procedure anton: how is this access organized from the second invocation of anton, with "otto" (being external) interrupting the purely internal calling chain? (Such problems are present in the PASCAL language currently and have been solved there, but it was complicated for users as well as implementors). Amount of work for X3J3: large. 6.3 New INTENT attribute: COPY_IN (100) Subject: There should be the possibility to specify COPY_IN as INTENT attribute to dummy arguments (meaning that the argument may be overwritten, but the value change must not be transferred to the caller). Rationale...: see repository. Amount of work for X3J3: medium. 7. Executable Statements 7.1 Controlling Pointer Bounds (2) Subject: The pointer assignment statement for array pointer variables should allow to specify new index bounds (together with the pointer target). Rationale...: see repository. Amount of work for X3J3: medium. 7.2 Selecting subarrays of non-rectangular form (26) Subject: Allow the use of implied-do control on the right hand side of a pointer assignment to an array pointer. Rationale...: see repository. Amount of work for X3J3: medium. 8. FORMAT processing 8.1 Variable Repeat Specifiers in Formats (48) Subject: It should be allowed that repeat specifiers in FORMAT specifications may be variables (and not just constants). Rationale...: see repository. Problems: It might be sufficient to establish a simple integer-to-charac ter conversion intrinsic function - say TO_CHAR(integer) - which returns the external character representation of any integer argument (the user could write such a routine himself using internal I/O, but this is very clumsy). Then the example problem (see repository) could be solved by FMT='10X,'//TO_CHAR(M)//'(2X,''NO'',2X)' and there would be no need for a new construct within the core language any more. Amount of work for X3J3: medium (small for the additional intrinsic). 9. I/O enhancements 9.1 STREAM I/O, Binary stream I/O (63, 63a) Subject: In parallel to the current record-oriented I/O, Fortran should also provide support for binary (stream-oriented) I/O which is usual in UNIX (and in the C programming language) and which deals with files that have no record structure. Rationale...: see repository. Amount of work for X3J3: large. 9.2 Non-advancing I/0 combined with free format, Extend non- advancing I/O to List-Directed I/O (63b, 65) Subject: Allow the combination of list-directed I/O with nonadvancing I/O Rationale...: see repository. Note: Why has this combination ever been forbidden? Just by accident, or was there any reason? Amount of work for X3J3: small. 9.3 Any Kind of Integer for I/O Specifiers (68) Subject: Allow integers of any KIND - and not just default integers - to be specified with I/O parameters (such as IOSTAT=integer-var, ...). Rationale...: see repository. Notes: The only "default integer" constraint which actually might create a problem (if the "default" should happen to be 2-byte- integers) appears to be the IOLENGTH parameter in the INQUIRE statement (all other "default" constraints only refer to error codes or formatted record length where I cannot imagine any real problems). Amount of work for X3J3: small. 9.4 Named Scratch Files (73) Subject: Allow names to be assigned to scratch files. Rationale...: see repository. Problems: If two programs (or program units) open the same file (i.e. file with the same name) as scratch file: do they get different files, or do they access the same file (and possibly get OPEN errors)? Amount of work for X3J3: small (may be medium). 9.5 Default I/O mode (76) Subject: Allow the default I/O mode for READ/WRITE statements to be ADVANCE="NO" (depending on some new OPEN parameter). Rationale...: see repository. Amount of work for X3J3: medium (simple, but probably many places to look at). 9.6 Recognition of TAB characters in Fortran input (79) Subject: Treat TAB characters like the corresponding string of blanks in (formatted) Fortran input. Rationale...: see repository. Amount of work for X3J3: small. 9.7 New keywords READ_EOR, READ_EOF, WRITE_EOR (?), WRITE_EOF (?) in INQUIRE statements (93) Subject: Create a way to inquire about the current EOR and/or EOF status of a file. Rationale...: see repository. Amount of work for X3J3: small. 9.8 New keywords IS_EOR and IS_EOF in INQUIRE, READ and WRITE statements (94) Subject: Create a way to inquire if EOR and/or EOF have occurred on a file. Rationale...: see repository. Amount of work for X3J3: small. 9.9 New keywords DEFAULT_READ and DEFAULT_WRITE in INQUIRE statement (95) Subject: Create a way to obtain the default unit number for READ or WRITE. Rationale...: see repository. Problems: The standard does not demand currently that the default units must be ordinary (numbered) units as well: this might create compatibility problems. Amount of work for X3J3: small. 10. Access to Features of the Environment 10.1 Command Line Arguments and Environmental Variables (20) Subject: Create some standardized interface (i.e. replace all those system-specific interfaces which nearly all vendors offer) to access command line arguments and/or environment variables. Rationale...: see repository. Amount of work for X3J3: small. 10.2 POSIX Binding to Fortran 90 (47) Subject: Provide some standardized interface to access (all?) POSIX features from Fortran. Rationale...: see repository. Problems: The requirement might be covered by the standard C-interface of POSIX in combination with the C interoperability. It will be difficult to keep up with the development of POSIX if the interface responsibility is not assigned to the POSIX committee. Amount of work for X3J3: large (POSIX is big!). 10.3 Operation System Support (86) Subject: Provide a standard interface to pass a command string to the operating system for execution. Rationale...: see repository. Problems: The requirement may be covered by 10.2 (see above). Since the syntax of the command string will not be standardized, one might as well leave the "command string execution interface" system dependent as well. Amount of work for X3J3: small. 10.4 Handling of error messages (99) Subject: Provide some standard interface to obtain some reasonable error message text for each IOSTAT... value produced by the processor. Rationale...: see repository. Problems: National language support? Context sensitivity of error messages (i.e. which message text is produced if the same IOSTAT value can be produced by two different error situations?). Amount of work for X3J3: medium. 10.5 Primitive graphic facilities in Fortran (102) Subject: Provide some elementary graphics features (e.g. "draw pixel", "draw line") which can be supported nowadays by nearly all (?) current terminal devices. Rationale...: see repository. Amount of work for X3J3: large. Notes: c. the more detailed description of the proposal (presented at the Dresden meeting) in the attachment as an illustration what exactly is intended. 11. New / better Intrinsic functions 11.1 Regularize RANDOM_SEED functionality (55) Subject: Provide some means to reset the random number generator in a non-repeatable way (and furthermore create a more comfortable interface for the repeatable reset). Rationale...: see repository. Amount of work for X3J3: small. 11.2 Generic COUNT_RATE Argument for SYSTEM_CLOCK (61) Subject: Allow real numbers as COUNT_RATE argument (not only default integers) in SYSTEM_CLOCK. Rationale...: see repository. Amount of work for X3J3: small. 11.3 Extend MAX, MIN, etc. to CHARACTER Data Type (64) Subject: Extend various MAX... intrinsics to accept character arguments (for regularity). Rationale...: see repository. Amount of work for X3J3: small. 11.4 Intrinsic 'size' function for derived types (80) Subject: Provide some intrinsic to obtain the (processor-dependent) byte size of Fortran data objects. Rationale...: see repository. Amount of work for X3J3: small. 11.5 Instrinsic 'sort' for arrays of intrinsic type (81) Subject: Provide some sorting facility. Rationale...: see repository. Amount of work for X3J3: small. 11.6 Intrinsic function 'fft' - Fast Fourier Transformation (82) Subject: Secure the availability of the "Fast Fourier transformation" on every Fortran processor. Rationale...: see repository. Amount of work for X3J3: small. 11.7 Four new elemental intrinsic functions: TRUNCATE, ROUND, IBCHNG,ICOUNT (90) Subject: Provide some new functions for rounding (of real numbers) and bit handling (within integers). Rationale...: see repository. Amount of work for X3J3: small. 11.8 PATTERN= in bit manipulation functions such as IBCLR, IBSET, IBCHNG (91) Subject: Improve the bit handling intrinsic functions. Rationale...: see repository. Amount of work for X3J3: small. 11.9 New transformational functions: POSITION and LOCATION (97) Subject: Offer new functions for easier positioning of an array element within some multidimensional array. Rationale...: see repository. Amount of work for X3J3: small. 11.10 New functions to handle arrays: SCRIPT and SCALAR (98) Subject: Offer new functions for easier positioning of an array element within some multidimensional array. Rationale...: see repository. Amount of work for X3J3: small. 12. Relaxation of Restrictions 12.1 Remove the restriction on the maximum rank of arrays, Greater than 7 Array Dimensions (24, 24a) Subject: Increase the number of array dimensions which has to be supported by every processor. Rationale...: see repository. Amount of work for X3J3: small. 12.2 Remove limitation on statement length (50) Subject: Increase the minimum statement length (currently 40*132 characters) which must be supported by every processor. Rationale...: see repository. Amount of work for X3J3: small. Attachment: =========== (to illustrate requirement 10.5 / repository entry 102) THE CANADIAN FORTRAN 2000 PRIMITIVE GRAPHICS PROPOSAL The Canadian proposal is that Fortran 2000 be given a set of primitive capabilities that would permit graphic objects to be placed on a display surface. Fortran now has very adequate facilities for developing the software required for performing the higher graphic operations such as clipping, scaling,the execution of other transformations, and doing three-dimensional modelling. However, it does not have the facilities for performing the elementary graphic functions such as drawing or picking a point on a display screen. The result is that a program written in Fortran must use non-standard features if it is to perform any graphic operations. Thus, if the program is to be later transferred to another different platform, the graphic part has to be re-written specifically for the new platform. While this limitation of standard Fortran may not present difficulties for Fortran users having the appropriate resources and technical knowledge, it does present difficulties, often insurmountable, for many Fortran users with fewer resources. In the past, Fortran has been especially suited for use by scientists and engineers who are experts in their own disciplines first, and programmers only secondly. These people badly need access to convenient computer graphics, not necessarily the powerful computer graphics required by CAD systems or commercial displays, but enough graphics to permit them to develop programs that will produce graphs, figures and diagrams. Even the computational efficiency of certain commercial graphics systems is not required because of the speed of modern CPUs. For example, many programmers and users could live with software clipping in Fortran rather than clipping by hardware or assembler, if the only alternative were non-portable programs. What is required is access to the very basic graphic primitives in a platform- independent manner. This would permit the computational power of Fortran to be used for the development of specialized in-house programs by scientists and engineers having modest computer expertise. Such programs could be easily moved from one platform to another. In this proposal, we have avoided, at this time, the exact setting forth of the primitive graphic features which we would like to see contained in Fortran 2000. These features should be the minimum required to permit a variety of types of graphic displays. Any feature that could be implemented with reasonably efficient software written in present-day Fortran should probably be omitted at this time. For example, no new Fortran features are required to do graphic scaling and panning. Present-day Fortran is very adequate for that purpose. Some of the features that should be provided are as follows: (1) Turning on and off of the graphics mode. (2) Some control over the number of pixels to be used horizontally and vertically to represent the display surface, of course subject to the limitations of the graphics hardware in use. (3) Some control over colour ranges, again subject to hardware limitations. (4) An ability to draw a point (a pixel) on a selected location on the display surface, using a colour selected from the colour palate in use. Once this capability is available, almost any graphic display can be done using present-day Fortran, although perhaps not as quickly as with specialized graphic systems. (5) An ability to pick a selected point on a display surface using a pointing device such as a mouse. This would permit drawing and editing directly on the screen. Some features that would be less essential but nevertheless desirable would be: (1) The drawing of straight lines between any two points on the display surface. This would permit the Fortran programmer to produce software that would draw a variety of curved and/or broken lines with more efficiency than if only pixels were available. (2) A minimum set of text fonts with size, colour, location and orientation under the control of the Fortran programmer. This feature would promote speed and simplify programming. (3) Boundary clipping. This may save the Fortran programmer some trouble. The objective would not be to provide in Fortran the resources necessary to develop efficient CAD or commercial display systems in a platform-independent manner. The programmers of such systems would be expected to have the technical and other resources to develop such systems for each individual platform intended to be used. The provision of the facilities for developing such systems in platform-independent Fortran could place an unreasonable burden on Fortran compiler writers at this time. It may be suggested that X-Windows, the various versions of Microsoft Windows such as 3.X, 95 or NT, or the hopefully forthcoming Posix graphic features, will have the effect of making our proposal unnecessary. In practice, at this time and in the foreseeable future, none of these systems has or is likely to have anything at all close to universal acceptance. Another alternative that may be proposed is a more widespread use of the GKS or PHIGS standards. The GKS standard is now approximately ten years old and substantial differences of opinion between different users seem to be impeding the updating of the Standard. The software necessary to implement the GKS Standard does not appear to be readily available for some important platforms. When it is available, it may be expensive for users with limited resources and it may provide much functionality that is not needed, redundant or even in the way for many users. By contrast, the Fortran code required to exploit the proposed primitive Fortran graphic functions can easily developed, published, and made available to Fortran programmers with limited resources. The required algorithms are generally readily available to programmers having some initiative. Something similar has already been done for certain platform-dependent versions of the programming language Basic. However, the benefits of such work in Basic have been limited because of the platform-dependence problem. The example of Basic is an interesting one. In spite of their substantial limitations, platform-dependent versions of Basic continue to be used on a substantial scale in scientific and engineering offices because these versions of Basic contain graphic primitives which can be used to good effect by unsophisticated programmers. I would be pleased to have the opportunity to discuss this proposal with any of the delegates to the present Dresden WG5 meeting on Fortran. Whitman Wright, Ph.D., P.Eng. Canadian Delegate for Fortran Dresden, July, 1996