Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!uflorida!novavax!hcx1!hcx2!bill From: bill@hcx2.SSD.HARRIS.COM Newsgroups: comp.lang.fortran Subject: Re: Fortran 88 Message-ID: <44400025@hcx2> Date: 22 Oct 88 15:12:00 GMT References: <2045@unmvax.unm.edu> Lines: 147 Nf-ID: #R:unmvax.unm.edu:2045:hcx2:44400025:000:8362 Nf-From: hcx2.SSD.HARRIS.COM!bill Oct 22 11:12:00 1988 /* Written 12:02 pm Oct 20, 1988 by hirchert@uxe.cso.uiuc.edu in hcx2:comp.lang.fortran */ Kurt Hirchert (hirchert@uxe.cso.uiuc.edu) writes: > and, as you note later, most U.S. commenters got their information from > presentations made by vendors opposed to the draft. Because of ISO > rules, the European presentations were allowed to give attendees copies > of the draft. Because of X3/CBEMA rules, attendees of U.S. presentations > had to order theirs from Global Engineering. Many either chose not to > because of cost or received their copies from Global Engineering so late > that they did not have time to adequately review them, so they simply > echoed what was presented to them. (I, too, could list particular > comment numbers.) Do you really to argue that people that had copies of > the draft are less representative than those who did not? This whole issue of "vendors" versus "users" really angers me. I took the time to go through the public comment and note opposing comments that came from organizations I knew to be heavy FORTRAN users. I selected only those letters that, based on the detailed comments, indicated a reasonable depth of review of the draft. Here is just a partial list (those marked with an asterisk proclaimed themselves to be "official positions" of that organization): Organization Number of comments from ---------------------------------------- ----------------------- ARCO Oil and Gas Co. 1 ATT Technology Systems 1 Amoco Corporation 1 * Boeing (various divisions) 17 Center for Lithospheric Studies 1 Chevron Oil Field Research Co. 1 Exxon Central Services 1 * Federal Communications Commission 1 General Electric (various divisions) 3 Jet Propulsion Laboratory 2 Lawrence Livermore National Labs 2 Los Alamos National Labs 11 NASA - Goddard Space Flight Center 2 National Center for Supercomputing Applications 1 (Mr. Hirchert's employer) U.S. Army (various installations) 3 In all, I counted 73 letters like this. Don't tell me it is just "vendors" and "uninformed users" that are opposed to the draft standard; it just ain't so! Also, I have been doing a survey of Harris FORTRAN users to find out more about their views on the draft standard as well as FORTRAN in general. So far, a very small minority have answered "yes" to the question "Are you familiar with the 8x draft?". One question I keep asking myself is this: If users are really hungering for major new features/changes in FORTRAN/77, why are they not informing themselves about X3J3 activities? I think it is because the premise is false; they are NOT hungering for major changes. Improvement, yes, but not on the order of the 8x draft. > and I'll bet that the U.S. presentations didn't talk about how > unrepresentative it is to consider the implementation time for many of > those FORTRAN 77 implementations. (Many vendors took FORTRAN 77 as an > opportunity to write new compilers based on new compiler technology > (e.g., writing in HLL's rather than assembler, using common back-ends for > code generation, using automatically generated parsers, etc. On the > other hand, vendors seem inclined to implement Fortran 8x as extensions > to their existing products. Indeed, many have already implemented large > parts of 8x in precisely this manner.) I think you just argued against yourself, Kurt. Most of the vendors who have implemented parts of 8x as extensions did so because they had already rewritten their FORTRAN compiler once; they didn't want to do it again. Moreover, those compilers were now "up-to-date" on technology, so the impetus for rewrite that existed with old FORTRAN/66 compilers no longer existed for them. However, that does not prove that all FORTRAN/8x features can be done as "add-ons" to a FORTRAN/77 compiler. FORTRAN/8x changes many of the assumptions that a compiler could make about a FORTRAN/77 program -- assumptions that most likely are embedded in the design of almost all FORTRAN/77 compilers. You want specifics? Okay. In FORTRAN/77, there is no need to have dynamic-sized temporaries; in 8x it is a must for array operations. In 77, you can throw away everything about a program unit once it is compiled; in 8x this is isn't true, because of MODULES. In 77, each procedure is self-contained; there is no information "inherited" from outside it. In 8x, MODULE and internal procedures inherit information about variables and types from outside the program unit. This isn't the whole story, either. The argument I find most compelling is this: Just about every compiler implementor I have asked agrees with my estimate of 8x compiler complexity at about half that of Ada. Now, we have a darn good Ada compiler. We bought the front-end, and we have a common back end known as CCG. Yet, for the three years since we started the Ada project, it has consumed at least 4 people full time, all year every year, just to maintain this product; there were even more involved in its development. We have NEVER had that many people working on our FORTRAN/77 compiler, even when it was being developed (with the same technology). >>It's real simple. If you don't get the vendors to sign up to >>producing compilers and supporting those compilers, NO new standard >>will be successful. It's ALGOL 68 again. A beautiful language >>that none of the major vendors implemented. That could have a >>lot to do with why we are still programming in FORTRAN and not >>ALGOL 68. > > Then again, the fact that no existing programs would run in the new language > may have had something to do with why there wasn't enough demand to get the > major vendors to do good implementations of Algol 68. (Several of the major > vendors did implementations, but typically they weren't very impressive.) > Fortran 8x is designed to support the existing base of programs as well as > offer new features to the Fortran community. Wait a minute. C was a new language (after FORTRAN); it has been successful. Pascal was a new language, and it has been moderately successful considering it was designed as a teaching tool. BASIC was a new language, and it has been successful. This argument is a non-starter. > Finally, let me make a couple of comments not directly in response to > Presley's. In the U.S., the trade press has tended to cover Fortran > standardization only when X3J3 produced a draft or report or when X3J3 > had major internal disagreements. In Europe, on the other hand, there > has been a great deal of continuing coverage. Also, most of the ISO > delegates have been involved in Fortran standardization for many years, > while a large part of the X3J3 membership (especially among those opposed > to the Fortran 8x draft) who joined within the last couple of years. Is > it possible then that the greater acceptance of the Fortran 8x draft > outside the U.S. (and by WG5, in particular) might be a result of > long-term familiarity with its contents, reducing the "fear of the > unknown" factor and providing a greater opportunity to assess and > appreciate the benefits as well as the costs of the new features. There are at least two other likely causes for greater European acceptance. One: they have spent so much time with 8x that it is now more familiar to them than FORTRAN/77. Thus, they fear going back to something they now don't know very well. Two: They have an enormous emotional investment in 8x; it is psychologically very difficult for them to give up on it. The Europeans have typically been more enamored of "neat features" in languages than in their ultimate utility. Witness "pass by name" in Algol 60. In fact, that is the real reason Algol 68 died: it had "neat" features but not a well-designed set of _useful_ features (witness the absence of I/O). Bill Leonard, X3J3 Member Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or bill%ssd.harris.com@eddie.mit.edu