From owner-sc22wg5@dkuug.dk Wed Feb 12 19:28:43 2003 Received: (from majordom@localhost) by dkuug.dk (8.9.2/8.9.2) id TAA69418 for sc22wg5-domo; Wed, 12 Feb 2003 19:28:43 +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 TAA69413 for ; Wed, 12 Feb 2003 19:28:42 +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 SAA10160 for ; Wed, 12 Feb 2003 18:28:52 GMT Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id SAA11394 for SC22WG5@dkuug.dk; Wed, 12 Feb 2003 18:33:24 GMT Date: Wed, 12 Feb 2003 18:33:24 GMT From: John Reid Message-Id: <200302121833.SAA11394@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Draft of N1511 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-sc22wg5@dkuug.dk Precedence: bulk ISO/IEC JTC1/SC22/WG5 N1511(draft, 12 Feb) Draft response to the ballot 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 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 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 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. TC10 and D h) 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 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 suggestions a) to m) in the conclusion section: 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. 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: to be written once WG5 has decided on 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: to be written once WG5 has decided on the UK suggestions. 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!! 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 implementors. 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: (if WG5 decides not to incorporate Van Snyder's TR into Fortran 2000) 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. 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 reuse of 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: To be written when WG5 has decided on this. .................................................................. 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.