From owner-sc22wg5@dkuug.dk Sun Dec 22 06:04:05 2002 Received: (from majordom@localhost) by dkuug.dk (8.9.2/8.9.2) id GAA12541 for sc22wg5-domo; Sun, 22 Dec 2002 06:04:05 +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 mailgate.urz.tu-dresden.de (mailgate.urz.tu-dresden.de [141.30.66.154]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id GAA12536 for ; Sun, 22 Dec 2002 06:04:02 +0100 (CET) (envelope-from wwalter@math.tu-dresden.de) Received: from [141.30.70.195] (helo=NBTS02.math.tu-dresden.de) by mailgate.urz.tu-dresden.de with esmtp (exim-3.32) for id 18PyHC-00063A-00; Sun, 22 Dec 2002 06:03:46 +0100 Received: from NWRW09.math.tu-dresden.de (NWRW09 [141.30.70.9]) by NBTS02.math.tu-dresden.de (8.9.3+Sun/8.9.1) with ESMTP id GAA09439 for ; Sun, 22 Dec 2002 06:03:45 +0100 (MET) From: Wolfgang Walter Received: (from wwalter@localhost) by NWRW09.math.tu-dresden.de (8.10.2+Sun/8.9.1) id gBM53jv08502 for SC22WG5@dkuug.dk; Sun, 22 Dec 2002 06:03:45 +0100 (MET) Message-Id: <200212220503.gBM53jv08502@NWRW09.math.tu-dresden.de> Subject: Germany's vote To: SC22WG5@dkuug.dk (ISO/WG5 for Fortran) Date: Sun, 22 Dec 2002 06:03:44 +0100 (MET) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Concurrent Registration and Approval Ballot for CD 1539-1, Fortran Part 1 ------------------------------------------------------------------------- On registration the German vote is: NO. On approval the German vote is: NO with comments. Our comments follow. 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.