Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!zen!ucbvax!MIT-MULTICS.ARPA!Klensin From: Klensin@MIT-MULTICS.ARPA (John C Klensin) Newsgroups: comp.os.vms Subject: Fortran 8X Message-ID: <871112153845.101088@MIT-Multics.ARPA> Date: Thu, 12-Nov-87 10:38:00 EST Article-I.D.: MIT-Mult.871112153845.101088 Posted: Thu Nov 12 10:38:00 1987 Date-Received: Sun, 15-Nov-87 07:32:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 106 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)