Path: utzoo!mnetor!uunet!husc6!hao!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert From: hirchert@uxe.cso.uiuc.edu Newsgroups: comp.lang.fortran Subject: Re: More 8x Information Message-ID: <50500021@uxe.cso.uiuc.edu> Date: 3 Feb 88 23:37:00 GMT References: <68000005@convex> Lines: 165 Nf-ID: #R:convex:68000005:uxe.cso.uiuc.edu:50500021:000:10156 Nf-From: uxe.cso.uiuc.edu!hirchert Feb 3 17:37:00 1988 There's a lot of misinformation about Fortran 8x being distributed these days. Take, for example, the information in > Summary of the FORTRAN 8x Issues > > By Presley Smith and Bob Metzger > CONVEX Computer Corporation It beings with a fairly accurate summary of the status of the proposed standard. I could quibble with some of the details, but more serious inaccuracies follow: >The main proponents of the proposed standard are government labs like >Lawrence Livermore, Los Alamos, etc. The committee is structured so that >each member gets one vote. The problem is that a company the size of >IBM is considered one member, but within the government, each lab, or >subentity can be considered a member. The Department of Energy labs >have several members on the committee, each with one vote. ... Actually, except for IBM, there are no companies on the committee, only individual members employed by various companies and other organizations. The authors are right that there cannot be more than individual member with the same employer. Note, however, that there are approximately 20 members on the committee employed by computer vendors and only 4 employed by DoE funded labs. (If you wish to consider all U.S. government funded labs, add in the two members from NSF funded labs.) Furthermore, 2 of the 4 members from DoE labs voted against the current draft (because of features that were missing). Where did the authors get the idea that the government labs are pushing Fortran 8x over the objections of the vendors. The truth of the matter is that a significant majority of both the vendor employees and the user employees voted to forward this draft. >The feeling of many of the vendors and of CONVEX is that the proposed >standard adds to much complexity to the language while still ignoring >features requested by the public -- such as bit data types and POINTERs. >Some features that are in general use, such as the DO WHILE and INCLUDE >statements, have not been standardized. Some of the proposed new features >will potentially cause *significant* performance degradation in both >compilations and executions. As a member of X3J3, I was proposing pointers two years ago. Other members proposed them even earlier. As best I can remember, none of the people currently opposed to the draft supported any of these efforts. It was only when it became clear that their other objections would not be sufficient to block the draft that they brought up the issue of pointers. [In fairness to the authors from Convex, they were not represented, so maybe they were interested in pointers all along.] Fortran 8x has a more general looping mechanism than DO WHILE and a more powerful information transfer than INCLUDE. X3J3 did not feel it appropriate to make the language still larger by adding these redundant features in the name of standardizing existing practice. I keep seeing claims that 8x will cause sigificant performance degradation, but except for the general comment that it is harder to compile a larger language, I've never seen them backed up with specifics. >Many times FORTRAN users say they want FORTRAN 8x because they know about >some portions of 8x, such as the array notation of which a *subset* has been >implemented by some vendors in their compilers. What they don't realize >is that with this favorite extension comes 33 new statements and a >*potential* that DIMENSION, COMMON, and EQUIVALENCE will be removed in >some future standard, causing vast amounts of code to be rewritten over >the next 10-20 years. Fortran syntax tends to use statements where an Algol-like language would use a reserved word. Hence, many of these new statements are just syntactic placeholders. E.g., you can now end a DO loop on an END DO statement and the ends of main programs, subroutines, and functions can now be END PROGRAM, END SUBROUTINE, and END FUNCTION rather than just END. Most of these new statements don't add much in the way of complexity. The potential that current features in the language might be removed in a future standard exists whether or not Fortran 8x is adopted. Fortran 8x *removes* this potential for all but a handful of features in the standard immediately following it. The only place that DIMENSION, COMMON, and EQUIVALENCE are singled out is in an appendix which has no legal significance. Because there a "superior" alternatives to these features in 8x, X3J3 believes that the use of these features will die out in much the same way use of the arithmetic IF has died out since the logical IF and block IF became available. Hence, X3J3 recommends against the continued use of these features in your programs. Note, that when and if these features will be dropped from the language will be determined by when and if people stop using them, not vice versa. > THERE ARE NO SUBSETS OF THE NEW FORTRAN 8x STANDARD... > YOU GET IT ALL IF YOU GET ANY OF IT. The version of 8x finally adopted might be a subset (or a superset) of what is currently proposed. Once adopted, you are free to implement a subset, just don't call it standard Fortran. The presence of the subset in FORTRAN 77 has caused all sorts of trouble for people that bought "standard-conforming FORTRAN 77" compilers and didn't realize they were getting the subset. X3J3 decided that official subsets weren't worth the grief. >The facts are that the proposed FORTRAN 8x: > > - Contains all of FORTRAN 77 plus most of the constructs of > the Ada language; it is nearly double the size of the > FORTRAN 77 standard. The new stuff corresponds in complexity more to Pascal than Ada. The more commonly accepted estimate is that 8x is about 50% bigger than 77. > - Adds 33 new statements. See earlier comment on how meaningful statement counts are. > - Retains 36 statements from FORTRAN 77. All of them. > - "Decrements" (i.e., proposes to make obsolete in the future) > 14 statements (like: COMMON, EQUIVALENCE, DIMENSION, > DOUBLE PRECISION...). As I said earlier, 8x warns that usage may make these features obsolete (over a very, very long period of time) and warns against their continued use. Usage, not the standard, will determine whether they are ever dropped. >The following table (taken from the IBM ballot) compares the size of >FORTRAN 8x and Ada: > > Item Ada FORTRAN 8x > > Statements 49 84 > Syntax rules 179 280 > Keywords and operators 84 144 > Intrinsic functions 49 97 From these numbers you are expected to conclude that 8x is bigger than Ada. The problem with that logic is that if you collect the numbers for FORTRAN 77, you will find they are comparable to the numbers show for Ada. Now if you believe that FORTRAN 77 is about the same size as Ada, I have some wonderful ocean-front property in Illinois I would like to sell you. :-) In other words, the differences in style between these languages makes comparing these numbers meaningless. >Another key problem in the standard is the addition of the dependent >compilation model, which requires a programming environment to be >developed for FORTRAN. Currently, when the compiler compiles a subroutine, >it only must know about the subroutine that it is compiling. In FORTRAN 8x, >the environment of the subroutine, information on *all the subroutines that >are related* to the subroutine being compiled must be known to the compiler >at compilation time (like Ada). Such a process will slow the compiler down, >considerably. Information need be known only only about a special kind of program unit, called a MODULE, and then only if the subroutine explicitly requests access to information declared in that module. If you don't use MODULEs, your compilations will remain independent. (If you use a MODULE, the compiler will be to read in the requested information stored in its internal representation. If you don't, you will have to provide that information in your source code, and the compiler will have to convert that text into its internal form. Do the authors really believe that binary input will be slower than textual input?) > Summary of Written Comments Deleted to save space. There are some errors here, too, but not so many. > Call for Response > >All members of the FORTRAN community are encouraged to find out more about >the FORTRAN 8x standard and to voice their opinions by writing to: > > X3 Secretariat > 311 First Street, NW, Suite 500 > Washington, DC 20001-2178 > > Phone 202-737-8888 Here we agree. Whether you like 8x or hate it, don't leave the decision making to others! >Draft standards may be ordered by contacting Global Engineering Documents, >Inc. at 1-800-854-7179. There will be a small fee to cover the cost of ^^^^^^^^^ Sadly, it is $50 for a 2-up photocopy. X3J3 wanted to obtain a wider distribution at a lower price, but the bureaucrats said no. >production and shipping to obtain a copy. Letters expressing opinions >should be addressed to this address. It is NOT a requirement that an >individual obtain a copy of the proposed standard in order to comment on it. > >Remember, if the user community does not take the time to examine FORTRAN 8x >and voice their feelings before February 23, 1988, the new >version will be approved in its current form. ... Literally true, but improbable. There is already enough comment in to assure that the current draft will not just be "rubber-stamped". It seems very likely that comments received during this period will serve as the basis for revising the 8x proposal. If there are any significant revisions to the proposal, 8x will have to go out for another public comment period before it can be submitted for approval. However, changes are less likely to occur as a result of a later public comment period, so now is the time to comment. Kurt W. Hirchert National Center for Supercomputing Applications