psmith@convex.UUCP (01/25/88)
-------------------------------------------------------------------
Summary of the FORTRAN 8x Issues
By Presley Smith and Bob Metzger
CONVEX Computer Corporation
If you've recently seen the rash of articles about FORTRAN 8x, you
might be curious as to what the fuss is all about. In the next few pages,
I'll try to give you some facts that will help you understand what
is happening with the proposed FORTRAN 8x standard.
Status of the Proposed Standard
The ANSI X3 committee approved the draft proposed ANSI standard, FORTRAN 8x
for public review on August 20, 1987. The results were:
31 for public review
4 against ... IBM, UNISYS, DEC, and DG
2 abstained .. Omnicom, Inc. and Railinc Corp
1 ballot not returned
One thing is interesting. DG had voted YES on both the letter ballot and
role call vote on the X3J3 FORTRAN Technical Committee but the DG
representative on X3, the management committee, voted NO.
Harris was the other major vendor that voted NO on the X3J3 committee.
They don't have a member on X3.
Public review started on October 23, 1987 and will terminate on February
23, 1988. All letters and comments must be in Washington, DC by
February 23, 1988.
During this period, the FORTRAN community has the opportunity to "vote" on
the proposed standard by reviewing the document and writing letters to
the committee. Each public comment must be answered in writing by the
FORTRAN Technical Committee, X3J3. If the FORTRAN community does NOT write
letters commenting on the proposed standard, then the standard will be
approved without change.
Details of the Issues
CONVEX, IBM, DEC, UNISYS, and Harris have all gone on the record as
opposing the draft FORTRAN 8x standard in its current form. This group
is not opposed to the entire 8x proposal, but believes that certain portions
of the proposal are not in the best interest of the FORTRAN community.
IBM, DEC, UNISYS, and Harris (and now Data General) all voted NO to
forwarding the proposed standard for public review. Some of their
comments and concerns are noted later in this paper.
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. IBM, DEC,
Unisys, and others are concerned about the investment that their customers
have in code that has been around for years. Other members of the committee
do not appear to have the same concerns for various reasons. Certain
members of the committee feel that the committee is on the wrong track,
and only public review will change the direction of the committee. Some
of these comments are summarized later in this paper.
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.
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.
THERE ARE NO SUBSETS OF THE NEW FORTRAN 8x STANDARD...
YOU GET IT ALL IF YOU GET ANY OF IT.
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.
- Adds 33 new statements.
- Retains 36 statements from FORTRAN 77.
- "Decrements" (i.e., proposes to make obsolete in the future)
14 statements (like: COMMON, EQUIVALENCE, DIMENSION,
DOUBLE PRECISION...).
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
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.
Summary of Written Comments
The following are selected ballot comments from some of the committee members
who voted NO to forwarding the proposed standard for public review:
IBM: "The difficulty with 8x lies not in the quality of the work that
X3J3 has done but rather in the somewhat surprising observation that
the result of X3J3's work is a new language, and not a revision of
FORTRAN."
DEC: "We believe that publishing this document may jeopardize the past
successes of FORTRAN in its attempt to make several major changes to
the language."
Unisys: "We feel that the addition of the entire package of modern programming
language features has warped the language nearly beyond recognition. It is
our opinion that the committee has spent too much time in language design at
the expense of standardizing current practice. We fear the proposed language
will no longer serve the community for which it was originally designed.
The promoters of the modern language additions, on the other hand, contend
that the language already fails to serve that community and that if the
committee does not make drastic changes to the language, users will abandon
it in favor of a modern language such as Ada. Our reply is: Let them use
Ada. To paraphrase Mark Twain, we believe the predicted demise of FORTRAN
has been greatly exaggerated."
BOEING: "The standard has deviated too far from FORTRAN 77."
Many of the people who voted YES to send the standard out for public review
don't really want the current version to become the next FORTRAN standard.
Many on the committee are frustrated that rational proposals for change
continue to be voted down due to the makeup of the committee. Many of
these committee members believe that public review will help give the
committee direction. The following are comments from ballots of members
of the committee who voted YES to forward the standard for public review:
Harris: (Voted YES on letter ballot and NO on roll call ballot) "We have
some serious misgivings about the draft, but are willing to see if a
public review indicates that the public has similar misgivings."
Cray: (Voted NO on letter ballot and YES on roll call) "The number of flaws
in the current document, in my judgment, make it unlikely that we will get
any meaningful public comment."
Masscomp: "...voted for the review to 'help readjust the thinking of the
committee...It's time to take this to the user community and see if they
are ready for it.'" (Quoted from Electronics Magazine, August 6, 1987,
page 32.)
Another point of view was expressed in the Electronics Magazine article
of August 6, 1987:
"The opposition to FORTRAN 8x frustrates X3J3 leaders. 'Nothing is going
away. Nothing will change from the programmer's viewpoint. There only
will be more available to them,' says Jerrold Wagener, vice chairman of
ANSI's X3J3 committee. Wagener, the research director for the Amoco
Production Co. in Tulsa, OK, represents a large FORTRAN user. He labels
most of the objections as 'red herrings or scare tactics' by compiler
suppliers who want to avoid the cost of reworking products." ... "Wagener
assures users that the more widely used decremented statements -- like
COMMON and EQUIVALENCE -- will not be eligible for removal until 2010.
CONVEX's Smith worries that the mere threat of losing statements could
cause thousands of lines of code to be rewritten at high cost to users
and at the risk of software errors. Wagener is sure this will not happen."
The CONVEX compiler group is NOT opposed to doing a new compiler, we just
want to make sure than when someone says "What about 8x?" that they know
what that REALLY means. Most commonly that simply refers to some favorite
proposed extension. Typically they do NOT know the entire scope of the
changes to the language, and the changes will be made in their FORTRAN
programming methodology if the standard is adopted without change.
There are many good features that will be of benefit to the FORTRAN
community, but remember, the FORTRAN user does not get only the features
that benefit him if the standard is approved.
To summarize: IBM's ballot comments appear appropriate (my comments in
parentheses):
O Large inventory of application code? YES, but...
8x does accept the existing FORTRAN 77 inventory, but that inventory
comes with COMMON, EQUIVALENCE, ENTRY,... all of which 8x says are
obsolescent and can be deleted from future versions of the standard
when their use becomes insignificant.
(The exact wording of the proposed standard is: "Better methods exist
in this document. It is recommended that programmers use these better
methods in new programs and convert existing code to these methods.
As the new features of this and subsequent revisions of the standard
supplant the deprecated features and they fall into disuse, it is
recommended that future FORTRAN standards committees move these features
from the deprecated list to the obsolescent list." Page B-2 and B-3.
(The argument on the other side is that it will be 20 years before
these statements will be removed if ever. The issue is how much
money and time will people spend converting programs with the
"potential" of removal in the future. Also, who will determine that
"enough" FORTRAN programs have been converted to make their use
insignificant. It's a threat that will hang over FORTRAN.)
O Preserve user investments in user training? NO.
8x provides FORTRAN 77 compatibility to support "dusty decks,"
programmers are encouraged to use only the new language. Of 72
statements in this language, 31 are new and many statements now
in common use are "discouraged." (A mixture of statements will
be a program maintenance nightmare--see example below.)
O Preserve vendor investments in reliable compilers? NO.
8x would have a major impact on many existing FORTRAN compilers.
All parts of a compiler would be affected by the significantly
larger language; dictionary phases are heavily impacted by qualified
names...and new data types. Code generation is further impacted
by structures, array language, and array descriptors.
...dependent compilation. The USE statement requires information
from other compilations. This requires new library services, both to
store and control this information. Other operating system services
are impacted: Link editing must now handle scopes for external names,
for example.
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
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
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. IBM, DEC, UNISYS, and CDC (who
voted YES for public review) are all working with their user groups to
inform them of the details of the proposed standard and are encouraging them
to write in and voice their opinions. alm@a.UUCP (Alex Marusak) (01/30/88)
In article <68000005@convex>, psmith@convex.UUCP writes: > . . . > Summary of the FORTRAN 8x Issues > > By Presley Smith and Bob Metzger > CONVEX Computer Corporation > . . . > The main proponents of the proposed standard are government labs like > Lawrence Livermore, Los Alamos, etc. . . The statement above is, I feel, misleading. While strong support for Fortran 8x has been voiced by some X3J3 members working at government labs, equally strong support has come from X3J3 members who are private-industry Fortran users, or who are employed by universities, or who are employed by computer software and hardware vendors. The number of X3J3 members working for government labs and voting 'yes' on the final (and critical) roll-call vote is FOUR. The number of X3J3 members NOT working for government labs and voting 'yes' on the final roll-call vote is TWENTY-TWO. By the way, I am the X3J3 voting member from Los Alamos National Laboratory; and on the final roll-call vote to affirm the letter ballot, I voted 'NO'.
hirchert@uxe.cso.uiuc.edu (02/04/88)
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