From owner-sc22wg5@dkuug.dk Mon Dec 23 13:42:43 2002 Received: (from majordom@localhost) by dkuug.dk (8.9.2/8.9.2) id NAA24926 for sc22wg5-domo; Mon, 23 Dec 2002 13:42: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 math.jpl.nasa.gov (math.jpl.nasa.gov [137.79.7.57]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id NAA24920 for ; Mon, 23 Dec 2002 13:42:39 +0100 (CET) (envelope-from vsnyder@math.jpl.nasa.gov) Received: from math.jpl.nasa.gov (localhost.localdomain [127.0.0.1]) by math.jpl.nasa.gov (8.12.5/8.12.5) with ESMTP id gBNCgQAY008612 for ; Mon, 23 Dec 2002 04:42:26 -0800 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.5/8.12.5/Submit) with ESMTP id gBNCgPuT008608 for ; Mon, 23 Dec 2002 04:42:25 -0800 Message-Id: <200212231242.gBNCgPuT008608@math.jpl.nasa.gov> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 X-Exmh-Isig-CompType: comp X-Exmh-Isig-Folder: inbox To: sc22wg5@dkuug.dk Subject: Germany's negative vote on F2000 Mime-Version: 1.0 Content-Type: text/plain Date: Mon, 23 Dec 2002 04:42:25 -0800 From: Van Snyder Sender: owner-sc22wg5@dkuug.dk Precedence: bulk > 1. The proposed Fortran language and document are TOO LARGE AND > MUCH TOO COMPLEX for anyone to learn or read completely.... The draft standard is roughly the same size as the 1999 C standard, and MUCH MUCH smaller than the C++ standard or the Ada standard. The sizes of the C and C++ standards (and the poor quality -- in my opinion -- of their exposition) seems not to have had a negative effect on their usage. > 2. The standardization process has become seriously DISCONNECTED > from the Fortran user community.... One particularly observable reason for this is that users aren't doing their part to produce the new Fortran standard, except to complain after the draft is published for comment. Out of roughly six billion souls on this planet, twelve routinely show up to do the work of producing a new standard. Roughly half of these are users. Of course, ANSI bears some of the blame for this, by charging $US 800 for the privilege of being an unpaid volunteer. We realize that travel from Europe or Asia to participate in meetings of the primary development body -- an American National Standards Institute committee -- is expensive, but e-mail is cheap. The primary development body has received very little correspondence from the user community. As one of only six users who routinely show up to work on the revision of the standard, I must remark that I would find nearly everything being added to be of use in my current work. In fact, I have an eighteen-page wishlist for additions that would improve the power of Fortran to express solutions to my problems without compromising its efficiency. Some of the things on my wishlist would go some way towards improving the reliability of software development, or its use after deployment. One example is a provision to support physical or engineering units for quantities, including during input/output. Observers of the US space program may remember that a several-hundred-million-dollar spacecraft was lost in the vicinity of Mars due to the use of incorrect units. > 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. See #1. > 4. The current revision does not focus on the PRIMARY INTERESTS > and the most pressing needs of the Fortran community. It focuses on the needs of the users who show up to do the work, many of whom also advocate the needs they perceive by reading or participating in discussion fora, such as the comp.lang.fortran news group. Also see #2. > 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. The only "large" additions in the current draft are derived-type input/output, object-oriented programming, and C interoperability. Most of the remaining additions and changes are either small, or natural extensions or regularizations of existing features in Fortran 95. > 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 . . . Historically, nearly every comment on every revision of Fortran has said "The revised language is too big, but I'd like to add the following stuff." > a) At least some of the OOP language is not nearly as important > for the typical Fortran user as we may have thought.... I had this thought at the outset of my work with the current revision, but I now see how object-oriented programming could be quite useful in my work -- which is primarily with libraries of computational mathematics software, and computational applications, such as data analysis for remote-sensing applications. My applications require quadrature, fast Fourier transforms, solving nonlinear least-squares problems (which involves substantial linear algebra), special functions, etc. They already benefit substantially from derived types, modules, array processing and other features of Fortran 95 that were lacking in earlier standards. > b) Should we not have initializers? These may be convenient but they're never necessary, as one always knows exactly when an object comes into existence. Finalizers are necessary, because one frequently doesn't know when an object ceases to exist -- such as when it's a temporary object that's an intermediate part of another expression. > 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? In my work, C interoperability will have an enormous practical impact. My work necessarily involves use of libraries written in C, but C is not the proper tool for the "main" part of my work. Fortran 95 is, and Fortran 2000 would be even better. I don't like how pointer interoperability is done, but having the facility is far too important to advocate to remove it just because I disagree with how it's 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? Of the "big" revisions, this is the one for which I presently envision having the least use. I can't speak for other users, but it wouldn't be a disaster in my view if we didn't do this. > 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? The time to complain about this was when the IEEE Technical Report was published. Part of the agreement for its production is that it would be incorporated into Fortran as nearly identically to its specification as possible, unless difficulties in implementation were found. > 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). This was on the revised program of work, after the addition of a complete intrinsic facility for interval arithmetic was rejected as too large an addition (see DIN's complaint #1). Thereafter, the delegates who promised to do the work in this area either became unable to attend meetings of the development committee, or failed to perform the promised work. > 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. I agree with the spirit of this comment, but I don't know the details of the reason for rejecting John Reid's proposed exception-handling mechanism. But see DIN's complaint #1. > 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. The UK response deserves at least the same careful attention as the DIN comment. > 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. Although there may not be any problem with implementation, the possibility that an operator has different precedence in different scoping units has serious implications for long-term ownership expense. > 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. This is being addressed by Technical Report 19767, which is an approved WG5 and SC22 work item. > 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? The problem with allowing to USE the module containing the USE statement arises from indirect USE. If A uses B and B uses A, it's impossible to compile either one of them first, so it will be available while the other one is being compiled. > 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: > [There follows a long diatribe that doesn't really add anything....] The first proposal for array constructors, during the development of Fortran 90, was to use square brackets. There were objections to this use because their positions in the ASCII collating sequence are occupied by "national use" characters in the ISO-646 standard. Having observed that square brackets are used in other languages for which ISO standards exist, that the first proposal for array constructors during the development of Fortran 90 was to use square brackets, and that there have been substantial urges from the user community to use square brackets for array constructors, the development body decided to use square brackes for array constructors. Although the DIN comment does not mention that the interval arithmetic community has strenuously objected to the standard "pre-empting" the use of square brackets for array constructors, while they want to use them for interval constructors, observers of the last several years' history have little doubt that that is the real motivation. Others have, however, dreamed of using square brackets for complex number constructors, quaternion constructors, Pauli spinor constructors, antisymmetric tensor constructors, or constructors for other mathematical objects. In connection with the above YAK comment, we are curious why Fortran's existing interval constructor, the colon, could not simply be generalized to real numbers, thereby serving this purpose. Other alternatives are to use a keyword constructor, as is done for the complex data type, and for derived types. In comments on the DIN comment, "Scott Robert Ladd" remarked: > > OOP is a way of thinking, not a language construct. Yes, the Eiffel > > and Smalltalk folk will burn me at the stake for saying so, but my > > assertion is true -- and even though I've long been a loud supporter > > of OOP, I do not see it as essential (or even desirable) if it gets > > in the way of clarity and efficiency. The only opportunity for inefficiency in the use of OOP arises from the automatic invocation of a type-bound procedure by way of a polymorphic object. Careful attention has been paid in the development of the OOP facilities of Fortran, so as not to make their use any less efficient than the explicit alternative -- a case selector. -- Van Snyder | What fraction of Americans believe vsnyder@math.jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.