From owner-sc22wg5@dkuug.dk Thu Jan 9 17:49:47 2003 Received: (from majordom@localhost) by dkuug.dk (8.9.2/8.9.2) id RAA52157 for sc22wg5-domo; Thu, 9 Jan 2003 17:49:47 +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 nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id RAA52145 for ; Thu, 9 Jan 2003 17:49:38 +0100 (CET) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id QAA27915 for ; Thu, 9 Jan 2003 16:49:37 GMT Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id QAA27418 for SC22WG5@dkuug.dk; Thu, 9 Jan 2003 16:53:57 GMT Date: Thu, 9 Jan 2003 16:53:57 GMT From: John Reid Message-Id: <200301091653.QAA27418@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Result of the ballot on the Fortran 2000 CD MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-sc22wg5@dkuug.dk Precedence: bulk ISO/IEC JTC1/SC22/WG5 N1506 Result of the ballot on the Fortran 2000 CD John Reid This is complete except that the US comments were submitted as PS/PDF and are available as N1509. ....................................................................... ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N3535 TITLE: Summary of Voting on SC 22 N 3501, Concurrent Registration and Approval Ballot for CD 1539-1, Fortran - Part 1 DATE ASSIGNED: 2003-01-07 SOURCE: SC 22 Secretariat BACKWARD POINTER: N/A DOCUMENT TYPE: Summary of Voting PROJECT NUMBER: 22.02.01.01 STATUS: The results of this ballot are forwarded to SC 22/WG 5 for review and appropriate action. This project has been registered at the CD stage on the SC 22 programme of work. ACTION IDENTIFIER: ACT DUE DATE: N/A DISTRIBUTION: Text CROSS REFERENCE: SC 22 N3501 DISTRIBUTION FORM: Def Matt Deane ANSI 25 West 43rd Street New York, NY 10036 Telephone: (212) 642-4992 Fax: (212) 840-2298 Email: mdeane@ansi.org _____end of cover page, beginning of document______________ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N3501 Circulated by: JTC 1/SC22 Circulation Date: 2002-09-27 Closing Date: 2002-12-27 SUBJECT: Summary of Voting on SC 22 N3501, Concurrent Registration and Approval Ballot for CD 1539-1, Fortran - Part 1 ---------------------------------------------------------------------- The following responses have been received on the subject of registration: "P" Members supporting registration without comments 13 (Canada, China, Czech Republic, Denmark, Japan, Republic of Korea, Netherlands, Norway, Russian Federation, Switzerland, United Kingdom, Ukraine, USA) P" Members supporting registration with comments - "P" Members not supporting registration 1 (Germany) "P" Members abstaining 1 (France) "P" Members not voting 9 (Austria, Belgium, Brazil, Egypt, Finland, Ireland, DPR of Korea, Romania, Slovenia) ___________ end of registration ballot, beginning of approval ballot _____________ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N3501 Circulated by: JTC 1/SC22 Circulation Date: 2002-09-27 Closing Date: 2002-12-27 SUBJECT: Summary of Voting on SC 22 N3501, Concurrent Registration and Approval Ballot for CD 1539-1, Fortran - Part 1 ---------------------------------------------------------------------- The following responses have been received on the subject of approval: "P" Members supporting approval without comments 10 (Canada, China, Czech Republic, Denmark, Republic of Korea, Netherlands, Norway, Russian Federation, Switzerland, Ukraine) P" Members supporting approval, with comments 3 (Japan, United Kingdom, USA) "P" Members not supporting approval 1 (Germany) "P" Members abstaining 1 (France) "P" Members not voting 9 (Austria, Belgium, Brazil, Egypt, Finland, Ireland, DPR of Korea, Romania, Slovenia) ___________ end of approval ballot, beginning of NB comments _____________ Germany The DIN Fortran working group appreciates the huge time investment and effort by many individuals, especially the members of the primary development body, to create the present document and to do so on time. However, depite this heroic effort, DIN believes that the current document is not sufficiently mature to pass this vote. In particular, DIN believes that some key decisions in the past have led to a very dangerous situation for Fortran, and the current document as well as the current ballot seem to indicate this. 1. The proposed Fortran language and document are TOO LARGE AND MUCH TOO COMPLEX for anyone to learn or read completely. The few who will need to read the document in its entirety are either members of a Fortran committee or professional implementors of Fortran (and there is a lot of overlap in these two sets). Even potential authors of secondary literature will most likely shy away from the task unless they happen to be long-term committee members. And there is absolutely no way to write a simple, straightforward book on THIS language unless you consciously drop a huge number of details and special rules. In any case, it will be extremely difficult to educate and train the typical Fortran programmer in this language, or even to convince him/her that there is useful stuff in the new standard (it has been difficult enough with F90 and F95). So it seems the only real experts left will be people who are NOT USING the language (but maybe implementing it). L'art pour l'art? 2. The standardization process has become seriously DISCONNECTED from the Fortran user community. Judging by its turnout, the national US ballot that closed in November clearly proves this point: apparently, there is nobody left out there who is willing to comment (or capable of commenting?) on this document. That is a disaster! 3. The other disastrous impression we have been getting over the past few years is that the language is collapsing under its own weight and complexity and has become UNMANAGEABLE even for the experts. Long discussions on hundreds of major and minor issues have been going on for so long and still seem to be going at full speed, even right through (and in) this ballot, that one has to wonder whether there is any convergence. Some issues that came up in the CCI process took the few remaining Fortran experts of this world many meetings and sometimes several years to sort out, and the final decision occasionally depended on recollections of discussions and perceived intentions at meetings that took place many years ago. And the stream of new problems and interpretation requests is not abating. It seems that there are two main ingredients in this infernal cocktail that make it uncontrollable: - the multitude of language levels and styles due to evolving programming paradigms (and due to the requirement that the new standard must essentially be compatible with the previous four), and - the lack of any kind of formalism or formal notation to define the semantics of the language in the standard. (Modula-2 has had a single request for interpretation in the last five years, and they were able to find the unambiguous answer by taking a close look at their formal description of the semantics - no change required.) There was a brief chance in Cadarache to stop evolving the old language and to further develop only its modern parts, but we missed that chance . . . 4. The current revision does not focus on the PRIMARY INTERESTS and the most pressing needs of the Fortran community. Fortran's viability depends crucially on its acceptance and usefulness in the NUMERICAL AND SCIENTIFIC COMPUTING community, and a significant portion of that community is also in the PARALLEL AND HPC BUSINESS. It is our conviction that, had any other language (including C++) delivered more than half the runtime performance of Fortran code consistently on large (vector or parallel) computers, the danger of losing the HPC community would be imminent. Honestly, we really haven't done much for them since Fortran 95 (except for much better IEEE support, but true exception handling is still sorely missing, for example). Conclusion: ----------- In the interest of Fortran's future and longevity, we urge WG5 to review the current list of new features and their priorities in light of the current state of the document as well as the current situation of the Fortran community and market. We list our opinion on some features that are currently included as well as a few that are currently not included. This list could be much, much longer . . . a) At least some of the OOP language is not nearly as important for the typical Fortran user as we may have thought (some committee members have been thinking along these lines, e.g. Dan Nagle in his recent article in Fortran Forum, and Keith Bierman in his recent comment). Of course, this is difficult to disect now . . . b) Should we not have initializers? c) We probably all wish Interoperability with C were a bit simpler. In retrospect, do we think it was worth the time and effort, and do we believe that it will have any "political" or "strategic" impact? d) Derived-type I/O became ugly and complicated when it had to be paired with the traditional Fortran way of performing I/O (synchronized traversal of format list and I/O item list). Maybe we should have started a new I/O paradigm at this point (procedural approach as in many other languages), but then what about format strings? e) Good IEEE support is certainly a must for Fortran, but using our facility is very cumbersome and awkward if you want to write truly portable code. The number of cases to distinguish grows exponentially with the number of features that may or may not be supported. Is there a remedy? f) Some IEEE features would be more useful if they were also accessible in another way. For example, instead of having to explicitly set the rounding mode and then perform an arithmetic operation, it would be useful to also provide the rounded operators directly, e.g. .ADDUP. or +> . This would make the implementation of interval arithmetic easier (and possibly more efficient if rounded operations are provided directly in hardware). g) Good exception handling is crucial for writing robust code in any application area, and this is certainly true for numerical programs. Both C++ and Java provide excellent models --- why can't we do this? John Reid's proposal was an excellent starting point, and it is one of the darkest chapters of Fortran history that it was killed. 2004 is MUCH TOO LATE for this, but can we really afford to do it EVEN LATER? Every serious numerical library and program is suffering because this feature is lacking. h) We agree with the UK's technical comment TC10 that the automatic (deallocation and) allocation of a left-hand side ALLOCATABLE array during assignment should finally be allowed and is LONG overdue. The ALLOCATABLE array concept was severely crippled right from the beginning because you could not and you still cannot have a right-hand side whose shape is only determined at runtime. i) We also agree with the UK that some features should be simplified or possibly deleted altogether, e.g. with their comments TC2, TC3, TC6, TC8, TC9, TC10 (see above), MTC6, MTC7, MTC8, MTC9, and MTC11, at least. j) A facility that allows the specification of the precedence of an operator with a user-defined operator name is long overdue and will not do any harm as some would make you believe. Let those who want to mimick their usual notation as closely as possible do as they like. This will have absolutely no effect on those who do not want to use this feature. Freedom!! k) (see Van Snyder) Separating the specification/definition from the implementation/body of a module should have been done right from the beginning, and some of us who had some Modula-2 experience were advocating this very early. Why were we not able to learn from Modula-2? Because some of us were hardly ready to even accept modules, let alone more advanced variants. l) Taking interface blocks out of the normal host association rules was among the biggest blunders we ever made, and the reason for doing it was so unimportant and wrong (somebody wanted to save a bit of time instead of taking a few minutes to look at his/her code more carefully). As we understand the current situation, one can now selectively IMPORT entities defined in the host module containing the current interface block. Wouldn't it be helpful (and easier) to (also?) simply allow USE M of the enclosing host module M, with the understanding that you get normal host association, not just a view of the PUBLIC entities? Once we allow USEing the host module, we may as well allow ONLY and get rid of IMPORT entirely. Seriously, do we really want yak (= yet another keyword)? m) For the following reasons we oppose an alternative, redundant and thus superfluous notation for array constructors in general and the use of square brackets for this purpose in particular: 1. There is absolutely NO technical reason why Fortran should need yet another purely syntactic variant of an existing, well established and perfectly good notation (there are too many ways to say the same things already) --- especially since the proposed syntax is really a purely LEXICAL variant of a notation that was only introduced by the Fortran 90 standard (the beginning of the "modern" era for Fortran). Indeed, just two simple global change commands in any editor will suffice to perform this local, context-free transformation: '[' -> '(/' and ']' -> '/)' --- if you are willing to accept that these changes will also be made in character literals and in comments. 2. Most syntactic variants were introduced into Fortran in order to improve the readability, reliability and security of Fortran code, not just the notation of an old (F66 or F77) feature/concept. In fact, they often led to important generalizations or other substantial enhancements of the functionality of the language. Noteworthy examples of this are ends of DO loops (and other block-structured syntax elements), attributes in type declarations, kind parameters, etc. . In the present case we cannot discern an enhancement of the existing language in any respect. Also, the proposed use of square brackets is highly unvonventional in mathematics and unusual in general programming languages (some specialized mathematical systems such as Maple are an exception). 3. The Fortran committees have repeatedly rejected new ways of saying the same thing, especially if it was only a different spelling. The long discussions about CONSTANT as an alternative spelling for the PARAMETER attribute spring to mind. It was rejected in the late phases of defining Fortran 90, and we believe it was discussed and rejected again for Fortran 95. 4. Some of the most popular languages around, among them C, C++, and Java, use CURLY BRACES { } to enclose the array elements in an array notation, and that is not the only use of braces in these languages. In these and many other languages since Algol 60, square brackets [ ] are used for array dimensioning and indexing, but NOT for array construction. Pascal also uses square brackets to construct sets, but not arrays (Pascal does not provide array constructors). Modula-2 does not provide array constructors either, but switches to braces for set construction, having discontinued the use of braces for comments. Square brackets are used for subrange types and for array indexing in Modula-2. Interestingly enough, Ada folows the example of Algol 68 and uses normal parentheses ( ) for array constructors. However, this is not an option in Fortran since it would result in ambiguities. 5. Array constructors were only introduced into Fortran through the Fortran 90 standard, and the decision then was that Fortran (or computers or the world) were not ready to use previously unused characters for this purpose. What has changed since the late 80's? Not much, really, except that the percentage of systems that do not have square brackets and curly braces in their character set has dwindled even further. Is that a reason to use these characters now? Not necessarily, but their use should certainly be considered. If Fortran really wants to, after almost 50 years of existence, start using these "new" characters, then it should do so very carefully and very deliberately, and with the consciousness that [ ] and { } are probably the ONLY bracketing characters besides ( ) there will ever be (for all practical purposes). Does Fortran really want to waste one of these two pairs of symbols on a redundant notation, thus precluding much more interesting uses, e.g. in parallel and high performance computing, for intervals, etc. ? We do not see Fortran ready to take this historic step at this time. Before making such an irreversible decision, we strongly recommend a thorough investigation and discussion of the potential uses of these "precious" symbols. Japan On approval, Japan's vote is "Yes with comments". The comments are all typographical or editorial and ordered by [page:line] as follow: [2:24] Change "(4.4)" to "(4.2)". [13:32] Add the case of a scoping unit of an interface body to "all program units and subprograms" to justify the "IMPORT state- ments" in Table 2.1. [24:7+] In Table 3.1, change "Vertical bar" to "Vertical line", i.e. the name of "|" in ISO/IEC 646 and ISO/IEC 10646. [71:6+] In NOTE 5.5, line 12, change "matrix" to "humongous_matrix". [91:16+] In NOTE 5.36, line 6, change "need" to "need to". [109:4] Move the rule R632 after R626. [121:7+] In Table 7.1, change "C I,R L,L" to "C C L" for rel-ops. [173:27] Delete "or a file positioning statement". This clause has been here for long, but we found it unnecessary and confusing. [253:12] Exchange this paragraph and the next. [255:9-24] Move all the R rules immediately after R1205. C1202 has a forward reference and is hard to read. [258:5] Adjust the space between "7.1.3" and "7.1.8.7". [261:13+] NOTE 12.14 should refer to NOTE 7.42. [265:9-10] The restriction that an actual argument corresponding to a polymorphic dummy argument must be polymorphic is, in our opinion, surprising, even in the case of dummy argument that is allocatable or pointer. Add a note explaining the intent. [292:9] Change "total number" to "Total number". [333:(positional)7] Add ")" after "FROM (12.7.3". [353:6-10] Exchange and renumber Subsections 13.8.1 and 13.8.2. [362:26] Change "[P,][R]" to "[P,R]". [378:] In NOTE 14.14, Change "--" to "-". [379:] In NOTE 14.15, Change "--" to "-" thrice. ==================================================================== United Kingdom UK Comments. 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-------------------------