tower@bu-cs.BU.EDU (Leonard H. Tower Jr.) (10/21/87)
Just forwarding this along. Suspect some of you could be affected down the line. enjoy -len ---------------------------------------------------------------------- Date: Mon, 5 Oct 87 10:16 EDT From: John C Klensin <Klensin@MIT-Multics.ARPA> Subject: Fortran 8X To: bboard@MC.LCS.MIT.EDU For anyone who might be interested, the proposed revised Fortran standard has been announced for public review. This version of the language, under development for several years, contains a large collection of extensions that give it much of the power and capabilities of languages like Ada (tm) including array operations, user-defined data types, facilities for modular data and procedure definitions, and "the concept of language evolution". This revision has been vigorously opposed by several parties on the grounds (among others) that it will make Fortran too large and complex to be mastered and used by major portions of its traditional user community. Many of the opponents have voted to expose it for public review only as a consequence of a belief that it is time that general opinion "corrects" the position of the majority position on the developing technical committee. On the other hand, the draft standard definitely has its advocates, who argue that these changes and extensions are needed to keep Fortran useful in the age of parallel machines and computations and/or to incorporate more modern language constructions. While no FORTRAN 77 features have been deleted, the draft standard identifies a very large fraction of traditional FORTRAN s obsolescent or deprecated. That list includes arithmetic IF, real control variables, shared DO termination, alternate return, ASSIGN and assigned GOTO, EQUIVALENCE, assumed-size dummy arrays, passing array elements or substrings, BLOCK DATA, the COMMON statement, the ENTRY statement, statement functions, non-generic names for intrinsic functions, computed GOTO, most of the DATA statement, the DIMENSION statement, and the DOUBLE PRECISION statement. In each of these cases, replacement facilities -- either more general or more aesthetically pleasing to the developers -- have been provided, and these traditional facilities are therefore redundant. The draft standard requires that both the old and the new functions be supported in parallel until such time as the old ones can be discarded, although there appear to be some restrictions on the use of both "old" and "new" features in the same program. The document, and the internal comments and objections to it, can be ordered for $50 from Global Engineering Documents, 800-854-7179. Comments should be sent to Catherine Katchurik, X3 Secretariat/CBEMA, 311 First Street NW, Suite 500, Washington, DC 20001, with a copy to the Board of Standards Review, ANSI, 1430 Broadway, New York City, NY 10018. Please do not comment on the basis of the summary above: I have a well-known position on this subject that has almost certainly influenced what I have chosen to include in the summary. If, on the other hand, you are a Fortran user, it is in your interests to obtain and review this document and comment (whatever your position). It is the clear, and quite public, intent of several members of the technical committee to get this draft standard approved and then use the government procurement process to impose it on all vendors and users. If this is desirable, then fine. If it is not, profuse and detailed objections now are the only way to stop it. The comment period closes 23 February. However, note that Global is often somewhat slow and the document is over 3/4 inch thick without the internal committee comments and not especially easy to follow, so order early if you are going to respond. I am not directly involved in the development effort, nor have I contributed to the draft standard, so don't comment to me -- this announcement is provided only as a public service, to give as much timely notice to the MIT community as possible. If you have colleagues who should know about this who don't see this list, please pass the notice along. ----------------------------------------------------------------------
CADS_COLE@GALLUA.BITNET (Kevin Cole; Gallaudet U.; Washington; DC) (11/11/87)
Sorry if this is a dead issue, but I've been shut out for a couple of weeks...
The first time I sent this, I was a bit more articulate in stating my case, now
I'm merely vocal.
<*FLAME ON*>
At the risk of offending several people, "For God's sakes, Why???"
If Pascal cannot do what you want, it's not FORTRAN's fault. The solution is
not to make FORTRAN look more like Pascal. I know several people out there
love Pascal but then several people hold wierd political beliefs too.
Personally, I like FORTRAN, C and assembler languages. But I'm not out to add
GO TO's to Pascal any more than I would prefer seeing constructs like:
ADD 31-CHARACTER-VARIABLE-NAME-ONE TO 31-CHARACTER-VARIABLE-NAME-TWO
GIVING 31-CHARACTER-VARIABLE-NAME-THREE.
added to assembler language. If you want to use "The Gross Verbose", that's
also your choice. But it ain't called COmmon Business Oriented Language for
nothing.
I know, I know, "Structure is great, structure is wonderful, structure is akin
to godhead, etc." So why not throw out every other language and force everyone
to use Pascal. And while you're at it, get rid of any computer that doesn't
use EBCDIC as it's primary character code. Herman Hollerith lives on!
(All replies should be sent in 80 character card format.)
<*FLAME OFF*>
--------------------------------------------------------------------------------
Kevin Cole <Flatline> BITNET: KJCOLE@GALLUA.BITNET
Center for Assessment and or
Demographic Studies (CADS) CADS_COLE@GALLUA.BITNET
Gallaudet Research Institute (GRI) UUCP: ...!psuvax!gallua.bitnet!kjcole
Gallaudet University CompuServe: 76167,1406
Washington, D.C. 20002
(202) 651-5575
"We go not quietly into that long dark gateway-less night"
"Alas, poor WISCVM SMTP, I knew it well."Klensin@MIT-MULTICS.ARPA (John C Klensin) (11/12/87)
Kevin, and anyone with similar instincts or reactions:
Whatever I, or anyone else, thinks of your comments and/or flamings, it
is critical that you understand one thing if you really do care about
Fortran, and especially if you would be "materially affected" by what
happens to the language: To a much greater extent than, for instance,
complaining here about a VMS bug without telling DEC, you have to
realize that no one is listening to *anything* but written comments
submitted to X3 and ANSI BSR. By contrast, those comments *will* be
listened to: the committee is required to respond to each and every one
of them. Some people have estimated, however, that it would take
roughly the same number that the first attempt at Cobol 8X got if you
want to send the committee back to the drawing board, rather than just
getting a few technical changes. The Cobol number was, for those of you
who don't know, around two THOUSAND.
Consequently, if you care:
1) Get a copy of the draft proposed standard and look at it. I
strongly recommend this step, rather than relying on hearsay about what
is there. For anyone who missed the earlier announcements, order from
Global Engineering Documents, 800-854-7179 or 714-540-9870, telex
692373. It will cost $50 for U.S.A. orders, $65 "foreign".
2) Write letters listing technical objections on a point by point
basis (it would be an act of mercy to the technical committee if you
number your points consecutively). Keep the flaming down and the
technical comments up. If your objections include "this is not the
FORTRAN I know and love", make sure you point out (a) why it will
adversely affect you and (b) why an answer to the effect that it
contains all the features of Fortran-77 and all Fortran-77 programs will
work, unchanged, with it, won't do it for you.
Comments that xxx belongs in xxx and not in FORTRAN (values of "xxx"
include, obviously, your favorite other language), can be "technical
comments", but only with arguments about impact and/or why compatibility
isn't enough.
Comments to the effect that [one of] the major advantages of Fortran
is that it is very small, easy-to-learn, and relatively free of
redundant features are also technical comments, but will have more
effect if they, too, come with clear statements of impact: e.g., it
would be helpful to point out what it will do to your annual programmer
training costs, and why it would not be reasonable for you to just train
people on the Fortran 77 subset if Fortran 8X came to be.
If you are going to complain about size for its own sake, you should
provide impact arguments there too: the advantages of simple languages,
relative charges from your vendor for licenses and support (current)
Fortran-sized compilers, vs PL/I-sized or Ada (tm)-sized compilers, and
what the higher charges might do to you, or whatever the impact would
be.
In essence, whatever is important to you. But write early, and write
in detail, and make sure that the impact is clear and significant.
3) The letters must be addressed to
Ms. Catherine Katchurik
X3 Secretariat/CBEMA
311 First St NW, Suite 500
Washington, DC 20001
... with a copy to ...
Board of Standards Review
American National Standards Institute
1430 Broadway
New York City, NY 10018
... and, anyone reading this from outside the USA should send an
additional copy to your national ISO member body, with a cover letter
indicating that you expect them to pursue this issue through ISO/IEC
JTC1/SC22 channels on your behalf.
Lest anyone point out that the thousands of comments on Cobol contained
a lot of form letters, those form letters said, in one way or another,
"this is incompatible, we have X zillion lines of code, the proposal
would require us to look at every one of those lines, it costs us Y
dollars to convert a line of code, therefore the revision is
economically unjustified". The proposed Fortran standard, by virtue of
an assertion that all Fortran-77 programs will operate correctly,
unchanged, avoids criticism from any comment that simplistic.
Finally, while this longish note (my apologies to everyone who couldn't
care less about Fortran) was prompted by a flame about the undesirabilty
of the proposed language, people who think is it the finest thing to
happen to Fortran since the IBM 704 should write letters saying that.
The complainers should, however, understand that the burden of proof is
on them: this is not a vote taken by weighing comments, the X3 and ANSI
mechanisms from the point of public exposure forward contain a strong
presumption that what the technical committee has proposed should, in
fact, be standardized.
Disclaimer #1: To the best of my knowledge, MIT has no institutional
position on the proposed standard. If it were to have one, I would have
no way of determining whether my personal position, which is not
discussed above in any event, reflected it.
Disclaimer #2: The above discussion is not intended to reflect a
position, mine or anyone else's, about whether or not Fortran 8X should
be approved, or how it might reasonably be modified. It is only an
attempt to be sure that all materially affected interests are informed
that there is a somewhat-controversial proposed revision of the Fortran
Standard available for public review and to provide information on the
types of comments that are appropriate and inappropriate and how those
comments should be handled.
Disclaimer #3: I am not a member of the technical committee. I also
do not have copies of the draft Standard that I can distribute or sell
to anyone. And substantially the total of what I can usefully
contribute to the discussion is above. Please don't send me any more
mail asking for copies of the document, or for comments on particular
features.
John Klensin
Internet: Klensin@INFOODS.MIT.EDU
BITNET: Klensin@INFOODS.MIT.EDU (strongly preferred)
JCK@MITVMA (if necessary)