ISO/IEC JTC1/SC22/WG5 N1520 Disposition of comments on the Committee Draft of Fortran 2000 John Reid WG5 thanks the national bodies that provided comments with their ballots (N1506 and N1509) and the Australian national body for providing an unofficial comment (N1499). WG5 responds as follows: .................................................................. US A. WG5 considered the following suggestions explicitly and accepted them except where indicated otherwise. 1.12 Add KIND parameter to IACHAR 1.14 Cater for the C types int8_t, int16_t, int32_t, int64_t, and intptr_t 1.20 Rename NONKIND as EXTENT. Not accepted. WG5 preferred to rename this as LEN. 1.21 Do not allow the parent component of a type to be specified as private 2.1 and 2.7a Give any object of CLASS(T) a component named T that represents its TYPE(T) subobject 2.2a Add optional MOLD argument to ALLOCATE to specify the dynamic type in the polymorphic case 2.2b Make intrinsic assignment apply to the dynamic type. Not accepted. The US delegation withdrew this request. 2.3 Reinstate deferred bindings 2.5 Require the BIND attribute in the ENUM feature 2.7b Disallow type mismatches when the dummy argument is declared with TYPE rather than CLASS 2.8 Should the transformational intrinsics such as CSHIFT be applicable to array of types with allocatable component? If so, exactly what is meant? 2.9 Replace the constants IOSTAT_END and IOSTAT_EOR by intrinsic functions 2.13 Add constants to specify the size in bits of the file storage unit, numeric storage unit, and character storage unit 2.14 Decide whether a program can have an intrinsic and nonintrinsic module of the same name 2.15 Allow BOZ constants to have a kind type parameter value. Not accepted. WG5 did not consider that this is needed. B. WG5 passed the following suggested changes to the Primary Development Body (J3) for consideration since they were editorial suggestions or very minor technical suggestions. All of section 1, except 1.12, 1.14, 1.20, and 1.21. Sections 2.4, 2.6, 2.10, 2.11, 2.12, 2.16. .................................................................. UK A. WG5 considered the following suggestions explicitly and accepted them except where indicated otherwise. TC1 Provide more support for ISO 10646 TC2 Remove the option of re-specifying the default initial value for the parent component when a type is extended TC3 Allow default initialization of parameter values of derived types TC4 Change type-bound generics to be sets of specific named type-bound procedures. TC5 Remove the facility to add type parameters during type extension. TC6 Allow a CLASS(*) pointer to point to an object of any type, including an intrinsic type. TC7 Allow any non-SEQUENCE type to be extended. TC8 Remove the TYPEALIAS facility TC9 Remove the ENUM facility. Not accepted. WG5 considers that this feature is important for interoperability with C. TC10 Treat the assignment to an allocatable array in the same way as to an allocatable array component TC11 Allow reallocation of allocatable arrays MTC1 Reword "NONKIND" as "LEN" MTC6 Change ACHAR(10) syntax within stream i/o MTC7 Allow input/output of IEEE exceptional values MTC9 Allow for IEEE extended format MTC10 Add a facility for controlling IEEE underflow MTC11 Have separate types for C data and procedure pointers MTC12 Make TYPE(C_PTR) be an opaque derived type MTC13 Require the prototype of an interoperable C function not have the inline function specifier MTC14 Add further requirement for C interoperability MTC15 Specify that the PROCESSOR_DEPENDENT i/o rounding mode should not depend on the rounding mode used for arithmetic. Not accepted. WG5 did not think that this change is needed. B. WG5 passed the following suggested changes to the Primary Development Body (J3) for consideration since they were editorial suggestions or very minor technical suggestions. Suggestions MTC2, MTC3, MTC4, MTC5, MTC8, E1-E22. .................................................................. JAPAN WG5 passed all the suggested changes to the Primary Development Body (J3) for consideration since they were editorial suggestions or very minor technical suggestions. .................................................................. GERMANY WG5 considered general comments 1. to 4. and suggestions a) to m) in the conclusion section. The WG5 responses are: 1. The proposed Fortran language and document are TOO LARGE AND MUCH TOO COMPLEX for anyone to learn or read completely. WG5 Response: Fortran 2000 was agreed to be a major revision of Fortran 95. WG5 has developed the proposals for Fortran 2000, described in WG5-N1259, which were approved by its members at the meeting in February 1997. It is true of many modern programming languages that few individuals are familiar, or need to be familiar, with all aspects of the language. 2. The standardization process has become seriously DISCONNECTED from the Fortran user community. WG5 response: This statement is not accepted. Members of the standardization committees who are employed by processor vendors are continually made aware of user requirements. Individual members of the standardization committees make frequent, usually daily, contributions to the main user forums for discussion of Fortran matters, viz comp.lang.fortran and comp-fortran-90, and major users are represented directly on the standardization committees. 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. WG5 response: Similar assertions about the size of Fortran 90 were made prior to its publication and have proved not to be true. Development of Fortran 2000 was guided largely by requirements expressed by users of the language. 4. The current revision does not focus on the PRIMARY INTERESTS and the most pressing needs of the Fortran community. WG5 response: As noted above, the content of Fortran 2000 was guided largely by users' requirements. Development of the language has been progressed as quickly as possible, given the constraint of the volunteer resources available. 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 . . . WG5 response: Some reduction has been made in response to the UK comments. Further, Section 4.5 (about 20 pages) has been reorganized because it made the OOP features seem more complicated than they actually are. b) Should we not have initializers? WG5 response: WG5 believes that structure constructors already provide sufficient functionality. This request seems to contradict request a). 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? WG5 response: It was agreed in Tokyo in 1995 that features for interoperability with C were required with sufficient urgency for the constuction of a Technical Report with a firm commitment to include its features in the next standard (see N1116, Resolution T9). While there have been difficulties in designing the features, the requirement has not been questioned within WG5 since. The features are still needed by the Fortran user community. Perhaps this is a request for simplification of the features, but there is no indication of how this might be done. 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? WG5 response: No detailed edits are provided and the suggestion of a completely different way of doing this does not fit with the goal of smooth upward compatibility with the existing features. 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? WG5 response: With the publication of TR 15580, WG5 committed itself to the inclusion of these features in the next revision of the standard. 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). WG5 response: The language contains the features needed to write operators such as .ADDUP. in a module. 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. WG5 response: John Reid's proposal did not reach a sufficiently polished state for inclusion and WG5 decided instead to follow the IEEE module route. This provides most of the necessary functionality and it is much easier to understand exactly what happens. 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. WG5 response: WG5 accepted the UK's technical comment TC10. 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. WG5 response: WG5 accepted all these proposals except for TC9. 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 mimic 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!! WG5 response: The absence of proposed edits to implement this suggestion make it impossible to judge the impact of this suggestion on the whole standard. However, it is clear that it will further increase the size of the revision and the burden on implementers. 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. WG5 response: WG5 is preparing a Technical Report that it hopes will be published at about the same time as the new standard. This will allow vendors to implement this feature ahead of the next standard with confidence that it will be included. Furthermore, if the feature is specified in a Technical Report, it is more likely to be implemented as an extension to Fortran 95. 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)? WG5 response: WG5 prefers having a new keyword with an obvious meaning to reusing an old keyword (USE) with a new meaning (host association). 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: WG5 response: WG5 decided to retain the use of square brackets for array syntax since this is wanted now by the community. If the standard is ever extended to support interval arithmetic, a suitable syntax for this will not be difficult to design. .................................................................. AUSTRALIA The comment from Australia was not official, but it was considered nevertheless. The request to change the remarks on module processing in section C was passed to the Primary Development Body (J3) for consideration since it does not involve any normative text. The request to change the USE default from public to private was not accepted since it involves an incompatibility with Fortran 95 and there is already a facility (the PRIVATE statement) to change the default in a module to private.