From owner-sc22wg5@dkuug.dk Fri Dec 13 13:14:18 2002 Received: (from majordom@localhost) by dkuug.dk (8.9.2/8.9.2) id NAA28040 for sc22wg5-domo; Fri, 13 Dec 2002 13:14:18 +0100 (CET) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from holyrood.ed.ac.uk (holyrood.ed.ac.uk [129.215.16.14]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id NAA28035 for ; Fri, 13 Dec 2002 13:14:16 +0100 (CET) (envelope-from dtm@holyrood.ed.ac.uk) Received: (from dtm@localhost) by holyrood.ed.ac.uk (8.8.7/8.8.7) id MAA18495; Fri, 13 Dec 2002 12:14:06 GMT Message-Id: <200212131214.MAA18495@holyrood.ed.ac.uk> Date: 13 Dec 2002 12:14:05 GMT From: D Muxworthy Subject: UK vote on Fortran 2000 CD To: sc22wg5@dkuug.dk cc: Nick Maclaren Sender: owner-sc22wg5@dkuug.dk Precedence: bulk This is a copy of the BSI Fortran Panel recommendation for the UK vote on the Fortran 2000 CD. It is currently working its way to the SC22 secretariat through the standards hierarchy and will no doubt eventually reach members of this list by a more formal route. Yuletide greetings to all our readers, David Muxworthy, for BSI Fortran Panel Concurrent Registration and Approval Ballot for CD 1539-1, Fortran Part 1 On registration the UK vote is: Yes. On approval the UK vote is Yes with comments. The comments follow. The BSI Fortran Panel wishes to congratulate the Fortran primary development body on bringing this major revision of the ISO Standard to the public ballot stage on schedule. A number of changes are proposed in the UK comments. These are in the nature of regularizing, simplifying and/or clarifying the language and do not introduce new concepts. It is intended, if they are approved, that their adoption should not delay final publication of the revised Standard. Members of the BSI Fortran Panel will provide detailed edits for all proposed technical changes in papers to be submitted to the joint WG5/J3 meeting in March and April 2003. The comments are divided into three groups: technical changes, minor technical changes and edits. Detailed edits for the first two groups will be provided later. Comments in the 'edit' group mostly relate to minor corrections or clarifications. Where the reason is not self-evident, a short rationale is attached; where detailed text is not supplied, it will be provided before the March/April 2003 meeting. TECHNICAL CHANGES TC1 Provide more support for ISO 10646. ISO 10646 support is incomplete in that there is no support for: - any of the file formats defined by ISO 10646; different file format choices will inhibit portability, - reading/writing numeric data to/from 10646 variables, and - mixing ASCII and 10646 data, despite 10646 being a superset of ASCII. Additionally, there are restrictions on reading/writing ASCII characters in a 10646 environment which appear to be impossible to check. The following features should be added to the standard to correct this: - allow the file format to be specified (to be UTF-8). - reading/writing numeric data to 10646 variables. - reading default character or ASCII data into 10646 variables. - assignment of default character or ASCII variables to 10646 variables. These requirements only to apply to processors which support ISO 10646. Edits will be needed to sections 4.4.4, 7.4.1, 9.4.5.8 and 10.6 (pages 38, 139-140, 183 and 224). TC2 Remove the option of re-specifying the accessibility and default initial value for the parent component when a type is extended This complicates the language with little benefit. TC3 Allow default initialization of parameter values of derived types This is an editorially easy change to make and will lead to consistency with the properties of intrinsic types. TC4 Change type-bound generics to be sets of specific named type-bound procedures. The generic type-bound procedure facility is difficult to understand and unnecessarily difficult to implement. It's confusing for the user when you explain that generic resolution produces a "slot number" in the dispatch table instead of a name. This confusion arises at least partly because although normal generics are a collection of (named) normal procedures, type-bound generics are a collection of UNNAMED type-bound procedures created by compiler magic from the list of the actual procedures implementing them at some level. It's also difficult to understand when, during inheritance, one is extending the generic vs. overriding an already-existing specific, precisely because the specifics don't have names. Section 4.5.1 Page 44 Syntax change: Instead of GENERIC :: => have GENERIC :: => Concomitant change: (a) The GENERIC statement always adds new specifics to the list, it never overrides them. (b) To override a specific within a generic, you use the specific name on the PROCEDURE statement, just like nongeneric tbps. i.e. to override a specific, you specific *the specific name*, to extend the generic, you specify *the generic spec*. Advantages: (1) Simpler exposition. (2) Simpler implementation. (3) Programs will be simpler to understand and maintain, because of the differentiation between overriding and extending. Disadvantages: (1) The user has to name the specifics instead of the compiler doing all the work. (2) The specific names have to be public if the user wants them to be overridable. TC5 Remove the facility to add type parameters during type extension. A derived type statement with an EXTENDS clause shall not declare any type parameters. The current description is incorrect, as SELECT TYPE provides no way to discover the values of any kind type parameters that were added during type extension. Furthermore, this feature complicates the language and adds little benefit. TC6 Allow a CLASS(*) pointer to point to an object of any type, including an intrinsic type. The restrictions are not necessary and exclude useful functionality. An example is for sorting of data of any type for which the ordering operators are defined. One should be able to select for intrinsic types in a SELECT TYPE construct. Pointer assignment should allow to be of a non-extensible derived type when is a pointer of CLASS(*) and has the dynamic type of . TC7 Allow any non-SEQUENCE type to be extended. There is no technical reason for the requirement that only extensible types can be extended; therefore it should be possible to extend any non-SEQUENCE derived type. However, SELECT TYPE should continue to require that its type guards specify extensible types (or intrinsic types). TC8 Remove the TYPEALIAS facility This complicates the language and adds little benefit. TC9 Remove the ENUM facility. ENUM complicates the language and adds little to the Fortran language per se; it appears to be of use only in conjunction with C. Moreover this definition inhibits future development of a more useful enumeration type. TC10 Treat the assignment to an allocatable array in the same way as to an allocatable array component Allocatable array assignment should be user-friendly the same way that allocatable component assignment is; that is, the destination array should be reallocated to the correct shape if it is of the incorrect shape. Thus, instead of having to say: DEALLOCATE (A) ALLOCATE (A(SIZE(COMPRESS(B)))) A = COMPRESS(B) one should be able to say A = COMPRESS(B) and have the same effect (except that if A has the TARGET attribute and is already the same size as B, it should be reused rather than go through the allocate-deallocate cycle - for compatibility with F90/95). TC11 Allow reallocation of allocatable arrays It should be possible to reallocate arrays; given the existence of the RESHAPE function this should apply to arrays of any rank. The value preserved should be via array element ordering, as with RESHAPE. We prefer a REALLOCATE procedure but could accept a facility like the SWAP_ALLOCATION procedure which has been suggested. MINOR TECHNICAL CHANGES MTC1 Reword "NONKIND" as "EXTENT" NONKIND excludes the possibility of extending to other non- kind parameters in future. MTC2 Remove ambiguities re VOLATILE The text needs to be clarified to avoid the problem of a variable being referenced while it is in the process of being changed. Possible edits are the following: Page 83: 8+ Add: If the value or properties of an object with the VOLATILE attribute are changed by means not specified in this standard, any change shall appear to the Fortran program as if it had taken place immediately before or immediately after the execution of an executable Fortran statement. Furthermore, when executing the statement immediately following such a change, the object shall be in a consistent state as if it had been changed by operations defined by this standard. and replace Note 5.23 by: The Fortran processor should use the most recent definition of a volatile object when a value is required, should make the most recent Fortran definition available, and should ensure that the above consistency rule holds. It is the programmer's responsibility to manage the interactions with the non-Fortran processes and to obey any constraints documented by the Fortran processor. MTC3 Resolve ambiguity re asynchronous i/o It is not clear whether pending i/o operations must be performed in order of program execution, in order for each unit, or may be performed in any order. The sentence 189:2-4 is ambiguous and needs to be changed. MTC4 Resolve ambiguity re error handing with asynchronous i/o What happens if an error occurs while several i/o statements are pending? A possible edit is the following: Page 189: 15+. Add new note 9.30a: If an asynchronous data transfer is pending when a synchronous data transfer is started on the same unit, or multiple asynchronous data transfer statements are waited on out of order, and an error condition occurs on any of them, it is processor dependent on which of the transfer or transfers it will be indicated, though it shall be indicated at least once. MTC5 Allow edit descriptors such as 1P2E12.4 This was a Fortran 66 facility which appears to have been omitted by oversight. A possible edit is the following: Page 219:19. Change "descriptor" to "descriptor, possibly preceded by a repeat specifier" MTC6 Change ACHAR(10) syntax within stream i/o Special handling of ACHAR(10) is unnatural to Fortran programmers. We recommend replacement by an intrinsic function such as NEW_LINE([KIND]), perhaps recommending that it have the value ACHAR(10). MTC7 Allow input/output of IEEE exceptional values Input/output of IEEE "exceptional" values should be specified. Currently, if the user has an IEEE infinity (or NaN), i/o is completely non-standard. Now that the standard supports IEEE arithmetic, it should specify the i/o results, and at least for the infinities should specify what they are (for NaNs it would be acceptable to make it "processor- dependent". Similarly, the results of various intrinsic functions (e.g. EXPONENT and FRACTION) should be specified for these values. MTC8 Add the value IEEE_NOT_IEEE to IEEE_CLASS_TYPE This is needed for implementing the module on systems which are basically IEEE, but do not implement all of it. It is analogous to IEEE_OTHER for IEEE_ROUND_TYPE. It might be needed, for example, if an unformatted file were written in a program executing with gradual underflow enabled and read with it disabled. MTC9 Allow for IEEE extended format IEEE_SUPPORT_DATATYPE and IEEE_SELECTED_REAL_KIND should handle IEEE 754 compliant "extended" types. We see no need to make a distinction between the extended and non-extended IEEE types here. MTC10 Add a facility for controlling IEEE underflow There should be a standard way of finding out, and setting on systems that permit it, the underflow handling mode. Many machines have settable "abrupt underflow" vs. "gradual underflow" and can run noticeably faster in abrupt underflow mode. We suggest adding procedures IEEE_SET_DENORMAL_MODE(HANDLED) and IEEE_GET_DENORMAL_MODE(HANDLED) with HANDLED of type default logical. The inquiry function IEEE_SUPPORT_DENORMAL_CONTROL() would also be appropriate. MTC11 Have separate types for C data and procedure pointers Function C_LOC operates on either pointers or functions. In C, pointers and functions are separate and it is confusing to mix them in Fortran. There should be a separate type C_FUNPTR for C function pointers. MTC12 Make TYPE(C_PTR) be an opaque derived type TYPE(C_PTR) should be required to be an opaque derived type. Allowing it to be an (alias for) integer invites unreliable programming practices. MTC13 Require the prototype of an interoperable C function not have the inline function specifier This is needed to remove possible linkage difficulties A possible edit is the following: Page 389:18+. Add: (7) The C function prototype does not have the inline function specifier. MTC14 Add further requirement for C interoperability Certain aspects of C interoperability have not been addressed: the following additional requirements appear to be needed: A C procedure shall not: (1) invoke longjmp where this would imply leaving an active Fortran procedure. (2) use signal (C std, 7.14.1) to change the handling of any exception that occurs in a Fortran routine or which is being handled by the Fortran processor. (3) perform i/o to a file that is currently connected to a Fortran unit, if a Fortran procedure has performed or will perform i/o to that unit. (4) close a file that is currently connected to a Fortran unit. (5) alter the floating-point status other than by setting an exception flag to signalling. If a C procedure reads the floating-point exception flags on entry, the result is processor-dependent. MTC15 Specify that the PROCESSOR_DEPENDENT i/o rounding mode should not depend on the rounding mode used for arithmetic It appears that there are no requirements on the "PROCESSOR_DEPENDENT" i/o rounding mode, so this could vary depending on the rounding mode used for arithmetic. That would be unfortunate and confusing. Suggested edit: Page 229:10 Change "other modes" to "other modes, and is not affected by the rounding mode used for arithmetic (14.3)". EDITS E1 Sections 4.5.1 and 12.3.2.1 Generic bindings and abstract interfaces are inadequately described. Further notes and examples are needed. E2 Sections 4.5.1.4 and 4.5.8 Page 49 - Note 4.28 and page 59 Note 4.55 Change the variable name 'abstract' in the example to 'summary' or 'synopsis' so as to avoid confusion with abstract interfaces in a text search. E3 Section 6.3.1.1 Page 111:4 Before "except" insert "corresponding to a nonallocatable dummy argument". E4 Section 8.1.4 Page 160:2-4 There is need for a rationale for using this construct along the lines of its increasing efficiency and avoiding the need for using the TARGET attribute. More detailed text will be submitted in due course. E5 Section 9 Page 171:16 After "file storage units" add "(9.2.4)" E6 Section 9 Page 171:21 Change "external file" to "external file (9.2)" and change "internal file" to "internal file (9.3)" E7 Section 9.4.1 Page 179:8 Change ", pad mode (9.5.3.4.2), and scale factor (10.7.5)" to "and pad mode (9.5.3.4.2)" Page 179:15 Delete the sentence "The scale factor ... 0." Rationale: Correction. The scale factor is not accessed by the OPEN statement. E8 Sections 9.5.3.7 and 10.6.5 The description of user-defined derived-type input/output at 9.5.3.7, although lengthy, is not very clear. The description at 10.6.5 is inadequate. In both cases further examples would be helpful, either in the text or in Annex C. E9 Section 9.5.3.7.2 Page 199:8 Change "dtio-generic-spec" to "dtio-generic-spec(R1208)" Page 199:16 and 199:32 Change "generic_spec" to "dtio_generic_spec" E10 Section 9.5.3.7.2 Page 201:17+ In Note 9.45 change "chose" to "choose". E11 Section 9.6.2 Page 204:23 Change: "A wait operation terminates a pending data transfer operation" to "A wait operation terminates (9.5.4) a pending data transfer operation". Rationale: Without careful reading of 9.6.1, this could be interpreted to mean that the wait interrupts and stops a data transfer operation. E12 Section 9.7.1 Page 206:0+ Change: "ERR=20" to "IOSTAT=N" E13 Section 9.8 Page 207:17+ Change in Note 9.59: "ERR=20" to "IOSTAT=N" E14 Section 9.8 Page 207:17+ Change in Note 9.58: "left vague" to "not closely defined" E15 Section 11.2 Page 246:6 Change "not themselves" to "not necessarily themselves" E16 Section 14 Page 355:20+. Add new note: NOTE 14.1a The reason that IEEE_INVALID is not required always in IEEE_EXCEPTIONS is to allow a non-IEEE processor to provide support for overflow and divide_by_zero. On an IEEE machine, invalid is an equally serious condition. E17 Section 14.2 Page 357:17 Change "examples" to "possible examples" Rationale: Not all CPUs will flag over-large integer values as an error. E18 Section 14.3 Page 359:20+ Add at the end of the paragraph: "The rounding mode may affect the result of an intrinsic function." E19 Section 14.7 Page 360:18-19 Replace "arithmetic operators" by "operators of addition, subtraction and multiplication" Page 360: 23-25 Replace "For each ... normalized" by "For each of the operators for addition, subtraction and multiplication, the result shall be as specified in the IEEE standard whenever the operands or arguments and IEEE result are normalized (if a floating-point value) or valid and within range (if some other type of value). Rationale: Exponentiation is not an IEEE operation. Fortran division is defined differently from IEEE division. E20 Section 14.7 Page 360: 28-29 and page 361:3. Change 'is as specified in the IEEE standard' to 'shall be consistent with the specifications in the IEEE standard'. Rationale: The IEEE does not specify all the Fortran intrinsics. E21 Section 14.7 Page 361:3+ Add new paragraph: "The inquiry function IEEE_SUPPORT_DENORMAL is provided to inquire whether the processor supports IEEE denormals. Where these are supported, their behavior for unary and binary operations, including those defined by intrinsic functions and by functions in intrinsic modules, is as specified in the IEEE standard." Rationale: Provides description for IEEE_SUPPORT_DENORMAL and regularizes situation compared to IEEE_SUPPORT_NAN and IEEE_SUPPORT_INF. E22 Annex E Page 533 Asterisk is used for so many different purposes in addition to multiplication, it is confusing to select only one of them for the index. The entry should be removed or should be made comprehensive. ------------------------------end of UK comments-------------------------