From whitlock@tle.ENET.dec.com Fri Oct 27 08:32:38 1995 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by dkuug.dk (8.6.12/8.6.12) with SMTP id IAA26251 for ; Fri, 27 Oct 1995 08:32:35 +0100 Received: from us2rmc.zko.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA15807; Thu, 26 Oct 1995 20:40:00 -0700 Received: from tle.enet by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA23583; Thu, 26 Oct 95 23:31:12 -0400 Message-Id: <9510270331.AA23583@us2rmc.zko.dec.com> Received: from tle.enet; by us2rmc.enet; Thu, 26 Oct 95 23:36:43 EDT Date: Thu, 26 Oct 95 23:36:43 EDT From: Stan Whitlock DTN 381-2011 ZKO2-3/N30 To: sc22wg5@dkuug.dk, cc@tle.ENET.dec.com Apparently-To: sc22wg5@dkuug.dk Subject: US F2000 items for the WG5 repository The following additions to the WG5 repository have been submitted to John Reid for inclusion in the Fortran 2000 requirements to be considered at the San Diego WG5 meeting. Another document for San Diego, sent separately, details the priorities for these and other WG5 repository items for F2000 consideration that the US determined at its August, 1995, meeting in Colorado. See you all in San Diego /Stan ******************************************************************************** Number: Title: Minor Technical Enhancements Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 000 Basic Functionality: This requirement is a placeholder to allow the development body to add small features and enhancements to the Fortran standard as it deems appropriate within the charter and schedule of the current draft effort. Rationale: This allows the development group to get informal agreement on adding small features to the standard without the delay of going through the formal requirements approval process. Estimated impact: Detailed Specification: History: Aug 95, meeting 134: Submitted, approved by US TAG for F2000 as high priority -------------------------------------------------------------------------------- Number: Title: Directives Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 026 Basic Functionality: Provide a suggested DIRECTIVE syntax for Fortran programmers. Rationale: Users of Fortran would benefit from more commonality of directives, and better mechanisms for identifying directives which are not safe to ignore. Estimated impact: Detailed Specification: History: Aug 95, meeting 134: Unarchived, approved by US TAG for F2000 as medium priority -------------------------------------------------------------------------------- Number: Title: Packaging Implementer Specific Intrinsics in MODULEs Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 027 Basic Functionality: Provide a mechanism to package non-standard intrinsic packages in a portable way. Various other standard activities are specifying new intrinsics as extensions to Fortran, and significantly polluting the name space. Using modules to hide these intrinsics will help reduce name space pollution. Rationale: Facilitates extensions to Fortran environments by other standard bodies (e.g. HPFF, X3H5, POSIX). Estimated impact: Detailed Specification: See the following references: X3J3/93-170 High Performance Fortran X3H5 document Fortran 90 Defect Item 122 History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority ---------------------------------------------------------------------- Number: Title: POSIX Binding to Fortran 90 Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 032 Basic Functionality: Provide, in a separate, collateral standard, a binding for POSIX that makes use of the new features of Fortran 90. Rationale: The existing POSIX binding to Fortran 77 is awkward and inefficient to use due to the limitations of Fortran 77. New features of Fortran 90, particularly modules and derived types, should make a much more natural binding possible. Without such a binding, Fortran (both 77 and 90) will remain a second class language on POSIX-compliant systems. Estimated impact: Detailed Specification: History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority ---------------------------------------------------------------------- Number: Title: Variable Repeat Specifiers in Formats Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 034 Basic Functionality: The language should be capable of repeatable Format specifier [sic; presumably proposer means variable repeat specifiers -- ed.]. For example: 100 FORMAT(1X,N(F6.2,1X),2X,N2X) 110 FORMAT(10X,M(2X,'NO',2X)) where N and M are values defined somewhere in the program by calculation, read, etc. Rationale: This capability would enable tables to be defined by read statements, etc., and make the programs more flexible and easier to write. Estimated impact: Detailed Specification: History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority ---------------------------------------------------------------------- Number: Title: Specifying Default Precisions Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 035 Basic Functionality: Allow a user to specify the precision used for the 'default real' and 'double precision real' types. Rationale: Under the current standard, each floating-point constant must include a suffix specifying the "KIND" or precision, else the interpretation defaults to the 'default real' type with processor-dependent precision. By allowing the programmer to specify the interpretation of 'default real' and/or 'double precision real' in one location per program unit (rather than with each of the individual occurrences of each literal constant) the reliability, portability, and readability of codes could be significantly improved. Many compilers allow such a specification by compiler option. This request is to make such functionality available in the language itself in order to enforce the availability and interpretation of the feature. (An alternative, of course, is to lobby vendors to provide such a feature more uniformly). Estimated impact: This would not invalidate any existing programs, however, some significant difficulties with storage equivalence might occur if 'default real' and 'double precision real' were set to the same "KIND". Storage equivalence between those types might have to be disallowed in each program unit using this feature. This is already the case with non-default "KIND"s so it should not be an insurmountable difficulty. Detailed Specification: For illustration purposes only: IMPLICIT (REAL,KIND=SELECTED_REAL_KIND(10,30)) (DEFAULT) The above would declare the 'default real' kind to be processor-dependent type which allows 10 decimal digits and an exponent range of at least 30. This would result in the selection of a 64-bit floating-point representation on almost all computers in current production, and is a verbose and indirect way of specifying 'default real' to be what most practitioners would prefer to refer to as "REAL*8". History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority ---------------------------------------------------------------------- Number: Title: Regularize Handling of Pointer Arguments Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 058 Basic Functionality: Treat pointer dummy arguments more like other dummy arguments. Rationale: Reduce surprise. Make operations involving pointers easier to express. Estimated impact: Most of the textual impact should be in the area describing allowed argument associations. Impact on conforming processors should be similarly contained. Detailed Specification: A suggestion: Allow INTENT specifications on pointer arguments, with the INTENT restrictions applying to the association of the pointer, not the value of the object with which the pointer is associated. Allow "pointer expressions" to be associated with dummy pointers subject to the same restrictions that apply to ordinary expression and dummy variables: the association denoted by the expression is evaluated once and then does not change even if the entities comprising it are modified, and the association of the dummy pointer may not be redefined. Treat a pointer-valued function reference as a "pointer expression" when it is being associated with a dummy pointer. Treat a parenthesized pointer reference as a "pointer expression" when it is being associated with a dummy pointer. Treat a variable with the target attribute as a "pointer expression" (a "pointer constant", if you will) when it is being associated with a dummy pointer. History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority ---------------------------------------------------------------------- Number: Title: Pointers to Procedures Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 059 Basic Functionality: Provide pointers which are associated with procedures rather than variables. Rationale: Such pointers would be a more convenient alternative to dummy procedures in many situations because they could be set once rather than having to be respecified in the argument list of each operation. Estimated impact: Because of the similarity to dummy procedures, most of the text changes would be straightforward. Code changes in conforming processors would likely be similarly straightforward. Detailed Specification: A suggestion: Procedure pointers would be declared with a POINTER declaration plus an interface block (or EXTERNAL statement?). The procedures which could be associated with such a pointer are exactly those that could be associated with a dummy procedure having the same interface. Procedure pointers would be allowed in derived types. There would be no ALLOCATE for procedure pointers. Pointers to procedures associated with an instance of a scoping unit would be valid only for the lifetime of that instance. History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority ---------------------------------------------------------------------- Number: Title: Greater than 7 Array Dimensions Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 067 Basic Functionality: The next Fortran standard should have a maximum limit on the number of array dimensions of greater than 7. Processors should be able to support more than that maximum as an extension. Rationale: The original limit of seven dimensions in Fortran was established when Fortran was first published in 1957 and has never been changed since. The number of heavy duty applications which require more than seven dimensions is growing and becoming a significant proportion of high performance applications. Since Fortran does not now support more than seven dimensions, programmers of an application which requires more than seven dimensions usually write their application in another language. They do this even though in most cases they are more familiar with Fortran and would prefer to use Fortran. Estimated impact: Detailed Specification: History: Aug 95, meeting 134: Change max 255 to >7, approved by US TAG for F2000 as medium priority ---------------------------------------------------------------------- Number: Title: Remove limitation on statement length Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 075 Basic Functionality: Allow a user to specify large parameter arrays in a simple way: allow more characters in the statement. Rationale: Fortran-90 introduced the useful capability of defining parameter arrays in a single statement. E.g. real, parameter :: a(4) = (/ 1.0, 2.0, 3.0, 4.0 /) According to the f90 language specification, a statement should be less than 132 character on each line, and contain less than 40 continuation lines. This puts severe restrictions on the size of a parameter array. E.g. if the array x(n_dim) is declared as double precision each element may occupy e.g. 16 ascii characters, which means that you may type 8 elements (132/16=8.5) on each line and a total number of 40*8 = 320 elements in the entire statement. This means that n_dim MUST be less than 320. Sometimes it's useful to define larger parameter arrays. E.g. for multi- dimensional arrays containing gauss quadrature or chebyshev coefficients. Estimated impact: Detailed Specification: A suggestion: This problem may be eliminated in case of the following modification of section 3.3.1.4 in ISO/IEC 1539:1991(E) : Remove the sentence: "A free form statement must not have more than 39 continuation lines." History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority ---------------------------------------------------------------------- Number: Title: Annex of processor dependent items Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 077 Basic Functionality: Include in the standard an annex that lists all the language features that have processor dependent aspects. Specifically all the language features where the standard indicates the results/values are processor dependent. This annex is not intended to include language features where there is an implied processor dependent nature (such as the result of arithmetic operations). Rationale: The list of language features where the standard indicates that there are processor dependent aspects appears to be growing with each new release of the standard. It would be helpful for implementers and users if a list in an annex detailed all the language features where some aspect of the semantics needs to be specified by the processor. The benefit for implementers is they get a check list against which to verify that their documentation includes definitions of processor dependent aspects. The benefit for users is they are alerted some areas of the language where they may encounter differences between processors. Once the annex is established further ideas for making use of the information might include (note these are not part of this requirement just ideas): - adding examples to the annex to show ways to write "portable" code with respect to the various items - require a processor to list in their documentation specifics for processor dependent behaviour for the items in the annex. Estimated impact: Detailed Specification: History: Aug 95, meeting 134: Submitted, approved by US TAG for F2000 as high priority ------------------------------------------------------------------------------- Number: Title: Asynchronous I/O (proposed HPFF work) Submitted by: US Status: For Consideration References: X3J3 JOR 95-004r1 item 080 Basic Functionality: Permit application control of overlapping computation and I/O. Formatted and unformatted I/O are required. The direction taken by HPF (which has been considering this facility) is similar to the old IBM VS FORTRAN implementation. If practical, this facility should be harmonized with HPF work in this area. It is envisioned that READ and WRITE statements will be augmented to allow control of asynch I/O (if it should occur, and a variable to contain the status of that particular I/O command). In addition a WAIT statement to allow the program to wait for the transaction to complete. It may be necessary or useful to augment the OPEN statement to limit asynch I/O to files that have been opened with for asynch I/O. It should be possible to test if an I/O transaction is completed without waiting. Ideally such a facility would handle multiple outstanding (pending) I/O transactions. Rationale: Advances in CPU performance continue to outstrip advances in input/output device performance. This is further aggravated by the increasing volume of multiprocessor computer systems. Many systems of the late sixties had such facilities (notably the IBM extensions and the CDC BUFFERIN/OUT) supercomputer users have found such facilities invaluable, and it is viewed as important enough in that community to have spawned an HPF subgroup dedicated to defining such a facility. Estimated impact: It would be necessary to be careful in defining how this interacts with ENABLE. It might be helpful to have loop-local PRIVATE variables. There are probably a number of other interactions not obvious at this time. Detailed Specification: A suggestion: As a first approximation, we should include the HPF text from their last meeting. Note that they are continuing to evolve their proposal. FWIW from memory: OPEN(...,synch='synch|asynch') READ(unit=,fmt=,astat=ivar,...) WRITE(unit=...,astat=ivar,...) WAIT (ivar) ! wait until done STATUS(ivar,iostat=) ! test if done, no wait History: Aug 95, meeting 134: Submitted, approved by US TAG for F2000 as high priority -------------------------------------------------------------------------------