walton@tybalt.caltech.edu.UUCP (03/31/87)
Two questions: (1) Can someone please tell me how to get an up-to-date copy of the Fortran 8x proposal? I have one dated January 1986. (2) Can someone who HAS a copy of the most recent proposal tell me if it is till true that an ALLOCATABLE actual argument must be matched by an ALLOCATABLE dummy argument? Please e-mail me as I don't read this newsgroup; besides, nearly all of you must know the answers anyway :->. Steve Walton guest as walton@tybalt.caltech.edu
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. ----------------------------------------------------------------------
bct@its63b.ed.ac.uk (B Tompsett) (10/26/87)
In article <14619@bu-cs.BU.EDU> John C Klensin <Klensin@MIT-Multics.ARPA> writes: > For anyone who might be interested, the proposed revised Fortran >standard has been announced for public review. [......] > > The document, and the internal comments and objections to it, can be >ordered for $50 from Global Engineering Documents, 800-854-7179. This number cannot be called from overseas. A regular phone number and address would be helpful. Brian. -- > Brian Tompsett. Department of Computer Science, University of Edinburgh, > JCMB, The King's Buildings, Mayfield Road, EDINBURGH, EH9 3JZ, Scotland, U.K. > Telephone: +44 31 667 1081 x2711. > JANET: bct@uk.ac.ed.ecsvax ARPA: bct%ecsvax.ed.ac.uk@nss.cs.ucl.ac.uk > USENET: bct@ecsvax.ed.ac.uk UUCP: ...!mcvax!ukc!ecsvax.ed.ac.uk!bct > BITNET: psuvax1!ecsvax.ed.ac.uk!bct or bct%ecsvax.ed.ac.uk@earn.rl.ac.uk
hgcjr@utastro.UUCP (10/28/87)
In article <700@its63b.ed.ac.uk>, bct@its63b.ed.ac.uk (B Tompsett) writes: : In article <14619@bu-cs.BU.EDU> John C Klensin <Klensin@MIT-Multics.ARPA> writes: : > For anyone who might be interested, the proposed revised Fortran : >standard has been announced for public review. [......] : > : > The document, and the internal comments and objections to it, can be : >ordered for $50 from Global Engineering Documents, 800-854-7179. : : This number cannot be called from overseas. A regular phone number and : address would be helpful. The address is ANSI X3 Secretariat, 311 First Street, NW, Suite 500, Washington, DC 20001-2178, USA. I do not have the phone number; sorry. -- Harold G. Corwin, Jr. UUCP: {allegra,ihnp4}!{noao,ut-sally}!utastro!hgcjr Internet: hgcjr@astro.AS.UTEXAS.EDU MaBell: 512-471-7463 Astronomy Dept., RLM 15.308, Univ. of Texas, Austin, TX 78712-1083
tower@bu-cs.BU.EDU (Leonard H. Tower Jr.) (11/03/87)
In article <14619@bu-cs.BU.EDU> > Date: Mon, 5 Oct 87 10:16 EDT > From: John C Klensin <Klensin@MIT-Multics.ARPA> > Subject: Fortran 8X > > 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". > > ... Date: Mon, 2 Nov 87 18:55:40 EST From: John C Klensin <KLENSIN@INFOODS.MIT.EDU> Subject: Fortran 8X posting Several people have sent mail inquiring how the Fortran 8X document might be obtained by people outside the USA, since the telephone number given works only *within* the USA, or have tried to order it from me (I don't have either copies or a distribution mechanism). For international inquiries, perhaps the best approach is to try to obtain the document through your own ISO member body, since the draft standard has been concurrently submitted for review in the ISO process. If it is more satisfactory for some reason, the U.S.A. supplier can be contacted as follows: Global Engineering Documents PO Box 2504 Santa Ana, CA 92707 USA Telephone: +1 714 540 9870 Telex: 692373 They list a price for "international orders" of $65. I don't know whether that is for air or surface delivery. It would probably be wise for readers outside the USA to send comments to both the ISO member body in your country and to the US apparatus. The latter should be sent to Catherine Katchurik, X3 Secretariat, 311 First St NW, Suite 500, Washington, DC 20001, USA, with a copy to Board of Standards Review, American National Standards Institute, 1430 Broadway, New York City, NY 10018, USA
cdb@hpclcdb.HP.COM (11/04/87)
> : > For anyone who might be interested, the proposed revised Fortran > : >standard has been announced for public review. [......] > : > > : > The document, and the internal comments and objections to it, can be > : >ordered for $50 from Global Engineering Documents, 800-854-7179. > : > : This number cannot be called from overseas. A regular phone number and > : address would be helpful. > The address is ANSI X3 Secretariat, 311 First Street, NW, Suite 500, > Washington, DC 20001-2178, USA. I do not have the phone number; sorry. No, the Secretariat has contracted out for documentation services to Global Engineering. Vital stats on the public review : Duration : October 23, 1987 to February 23, 1988 Copies of the Draft Standard are $50 from Global Engineering Documents Co. (714) 540-9870 (worldwide) (800) 854-7179 (West Coast - toll-free) (800) 248-0084 (East Coast - toll-free) Ask for the X3.9 Standard. Send Comments to : X3J3 Public Review c/o CBEMA Suite 500 311 First Street, N.W. Washington, DC 20001-2178 (CBEMA is the ANSI X3 Secretariat) ANSI procedures require the technical committee (X3J3) to reply to EVERY public review letter received during the review period. For those who find $50 a little steep or standardese a little ( :-) ) boring, two members of X3J3 have written a tutorial book, "FORTRAN 8x EXPLAINED" which is available for $19.95 from Oxford University Press, 200 Madison Avenue, NY, NY 10016, (212) 679-7300. I haven't seen the book yet, but (sight unseen) it has to be more readable than ANY standards document. Before anyone asks, no, I don't have any financial interest in the book. I will admit to liking its authors and its likely slant on the draft Standard. The above isn't a commercial - the below is. Please write the committee with your comments, both positive and negative. Three or four (very) large computer vendors are opposing the draft Standard and there have been rumors in print (e.g., "Datamation", October 15, 1987) of letter-writing campaigns organized by these vendors, presumably through their users' groups. In other words, this is all very political. Assuming that something you like is safe and inevitable since it's in the draft - isn't. Somehow I doubt that I need to encourage the writing of negative letters :-). There is some work going on by X3J3 in parallel with the public review. Three main additions are being proposed and considered : Kanji support, some sort of pointer facility, and reconsideration of BIT data type. "Being considered" means exactly that, no prognosis is possible at this time. X3J3 meets next week in Fort Lauderdale and again in February at New Orleans. Carl Burch hplabs!hpda!cdb
jerry@violet.berkeley.edu ( Jerry Berkman ) (11/05/87)
>The above isn't a commercial - the below is. Please write the committee with >your comments, both positive and negative. Three or four (very) large computer >vendors are opposing the draft Standard and there have been rumors in print >(e.g., "Datamation", October 15, 1987) of letter-writing campaigns organized >by these vendors, presumably through their users' groups. In other words, >this is all very political. Assuming that something you like is safe >and inevitable since it's in the draft - isn't. Somehow I doubt that I >need to encourage the writing of negative letters :-). > > Carl Burch For those of you who have not yet heard about the standards, don't believe "Datamation". The article is confused. "Datamation" says on page 24 that the 8x standard is: '"decrementing" 14 statements (meaning they're candidates for removal in the next FORTRAN standard), including COMMON and EQUIVALENCE, two of the most widely used FORTRAN statements.' Wrong! The 8x standard defines three types of undesirable features: "deleted features: features to be deleted in 8x, no features are in this category. "obsolescent" features: features to be reexamined for Fortran 9x and possibly deleted in 9x. ex: ASSIGN, PAUSE, floating point DO loop indices "deprecated" features: features to be reexamined in 9x and possible changed to "obsolescent" in 9x and possibly deleted in 10x. ex: COMMON, EQUIVALENCE, BLOCK DATA, etc. While Datamation talks of "decrementing", the standard does not. And Datamation has moved up the possible deletion of COMMON and EQUIVALENCE from 10x (about 2010?) to 9x (about 1999?). The article reports the vote was 30 for sending the standard out for public review, 5 against, and that the negatives included IBM, DEC, Unisys, and Data General. I hope this is more accurate than their summary of "decrementing". I have heard that some of the committee voted yes not because they favor the standard, but because they felt the need for public review to get back in touch with the user community. I think it is very important for people to read the standard and comment upon it. We are going to have a seminar or series of seminars at U.C. Berkeley to try to understand the proposed standard before sending in our comments. Jerry Berkman, Academic Computing Services U.C. Berkeley, (415)642-4804 jerry@violet.berkeley.edu
landers@cevax.berkeley.edu (Joe Landers) (11/17/87)
The FORTRAN 8x document (X3.9) describes a "FORTRAN family of standards" which include 3 categories: new features, primary features and decremented features. The last, "decremented features" has 3 subcategories for what the committee considers "outmoded" language features. They are: "deleted features," "obsolescent features" and "depreciated features." While the definitions and reasons for the terms are described, THERE ARE NO DELETED FEATURES IN FORTRAN 8x. rick@svedberg.bcm.tmc.edu writes [I folded the long lines.]: > ... >You will force a rewrite of many millions of lines of working code. > ... >I have no objection to an evolutionary path for an existing >language, but to totally rework the definition as it seems to be >proposed is stupid. No modifications of existing programs will be necessary because the standard is "upward compatible" with FORTRAN 77. I, too, think that a language should evolve, but there is disagreement on the level of evolution. Two important concepts have arisen out of programming language design in the last 20 years. The first is the concept of "data types." [A data type is a set of values, a description of the operations defined on them and a notation for using them.] The second is "variable scope." [The scope of a variable is the piece of a program where the name of the variable has the same meaning]. The FORTRAN 77 language standard provides only a small set of built in data types which are tied to the underlying machine architecture. A single precision variable on one machine may have a larger range and precision than a single precision variable on another machine. The only data structures permitted in FORTRAN 77 are the array and the common block. The FORTRAN 8x standard allows the user to define new variable types in terms of either simple "basic" types or in terms new, defined types. Data types may be parametrized. While there still is no pointer type, array objects may be allocated dynamically. You can specify floating point numbers by exponent range and digits of precision. Operations on arrays are available. In FORTRAN 77, the data associated with a variable may become associated with other names through the use of COMMON and EQUIVALENCE statements. All variables in a COMMON block are available in the program segment where the COMMON block is included. Furthermore, there is no mechanism to check the integrity of a COMMON blocks with the same name. If you change one variable in the middle of a block from type "integer" to type "double," there is no mechanism to propagate the change. In FORTRAN 8x, a MODULE/USE facility is available. Common data structures and programs can be grouped into a MODULE (and optionally defining some portions as PRIVATE) and USE'd in different subprograms. When a definition in a MODULE is changed, all of the modifications are carried out. mcdonald@uxe.cso.uiuc.edu writes: [I folded long lines.] >Perhaps someone will explain how my present programs will work >without common, if they now use it? Will you volunteer to convert >all my old programs to F8X or C. If you won't do the job for me, >why not? Your programs will work the same, because COMMOM blocks are still part of the language definition. It will not be necessary (at least in 8x) to convert ANY programs. If you write new programs, however, you might want to try the new facilities because they offer a lot more power and flexibility to your programming style. rick@svedberg.bcm.tmc.edu writes (again): >There are three rubs here. > ... (some rubs deleted) >3) There is no guarentee that a vendor will always provide the f77 >compiler if he is only required to provide a fortran compiler. > >I do believe that a good case could be made for developing a >language for sicentific use to replace Fortran which does reflect >the progress over the last 30 years in language development, just >don't call it fortran. Again, 8x is upward compatible. Programs which conform to the FORTRAN 77 standard will run under 8x. And again, I too believe that a good language for scientific computing is necessary. The problem, as you described, is to take advantage of the already existing large body of FORTRAN code. Should the modifications to FORTRAN only involve cosmetic changes in control structures? What do you gain in writing FORTRAN programs where each element of an array has to be explicitly referred to? Couldn't a vendor do a better job by supplying a collection of array intrinsics (as in 8x) rather than have you write them each time? I believe that FORTRAN 8x is a very valuable and worthwhile extension. It seems to me that it provides the programmer with some very powerful tools, without destroying the investment in the large body of existing code. joe landers landers@cardinal.berkeley.edu P.S.: You can order a copy of the standard, X3.9, from Global Engineering Documents, Santa Ana, California. (800)854-7179 or (714)540-9870. Mine came without a cover, looks like a third generation copy, and it costs $50.00, but you should get it and send your comments to ANSI. It's interesting reading.
landers@cevax.berkeley.edu (Joe Landers) (11/19/87)
mcdonald@uxe.cso.uiuc.edu writes: >... If C were not designed for scientific programming, why would it >have Bessel functions? Bessel functions are not part of the C language, they part of the C math library. The FORTRAN language supports "intrinsic" math functions. It makes these functions much easier to use. In C, the math library functions are not intrinsic, so you have to remember to include <math.h> or declare them "double" or else you'll get meaningless results. cik@l.cc.purdue.edu writes: >The article gives 21 FORTRAN features slated for eventual deletion. >Some of them I have not used, but about 15 of them are simple >constructs, easy to use, and not easily replaced by anything >reasonable. I suspect that another person will find the same >about the ones I have not appreciated. We need more powerful >languages, not language police. Could you please give some examples? From reading the X3.9 document, I get the impression that the committee WANTS to provide a lot of flexibility in the language without removing old features. They are interested in keeping the standard as "upwardly compatible" as possible. Of course the current vote is on 8x, but consider this proposal for FORTRAN 9x. Suppose in 9x, that code is marked as 'contains old features' or 'contains no old features' on a subprogram by subprogram basis. The standard might say: "If it's got an 'old features' than it must work as it did before but it can't contain any 'new features.'" This way, the language could stay reasonably small and still provide compatibility for older FORTRAN programs. Would this be satisfactory? Just a thought. I don't think ANSI could ever justify removing any construct from the language. joe landers landers@cardinal.berkeley.edu
ags@j.cc.purdue.edu.UUCP (11/20/87)
In article <21861@ucbvax.BERKELEY.EDU> landers@cevax.berkeley.edu (Joe Landers) writes: >Bessel functions are not part of the C language, they part of the C >math library. The FORTRAN language supports "intrinsic" math functions. True, but Bessel functions are not among the intrinsics specified in the FORTRAN standard. Bessel functions, if they are available at all, are generally part of a separate math library in FORTRAN, just as they are in C. >Just a thought. I don't think ANSI could ever justify removing >any construct from the language. Several antiquated FORTRAN constructs have already been removed from the language: Hollerith constants, Hollerith data, extended-range DO loops, labeled END statements, and reading into an H edit descriptor in a FORMAT statement, among other examples. None of these are part of the 77 standard. What's that you say? You didn't know Hollerith constants and data had been removed from the language? Well, now you know. -- Dave Seaman ags@j.cc.purdue.edu
richh@pnet02.cts.com (Rich Herzog) (02/14/88)
From what I have read here, I will be preaching to the converted,
but I cannot resist...
I have read the FORTRAN 8x draft, and I continue to be amazed at
the ability of a sanctioned standards committee to isolate itself
from global reality, and lose sight of its original purpose. Now,
one can hardly blame the committee members for attempting job
security in perpetuity, but this is hardly the way. It is very
clear to me that under the guise of 'refining' and redefining the
FORTRAN language, the committee members have actually defined ---
YES-- YOU GUESSED IT--- Ada !
They are attempting to change a stable, useful standard into something
that ALREADY EXISTS !
If I were a government contractor having to propose a configuration
management and lifecycle maintenance plan for a large project with a
20-year commitment, I don't know what I'd do. You'd pretty much have
to insist that the compiler, linker, etc and the system on which the
software was developed be stored so that changes can be made long into
the product lifetime.
I'm all for applying good software engineering practices to development,
but 8x goes over the line. Large software-engineering oriented projects
are already being done in Ada, which it's good for. (Aren't you glad
there something?). Medium-scale real-time and scientific applications
up to perhaps half a million lines as an upper bound) are still best
served in FORTRAN where appropriate.
Removing 'classic' features, change for the sake of change, and adding
new meaning to existing constructs does no one good.
Will I be the first to suggest that we begin to refer to the proposed
change as 'FORTRAN 9x' as there seems little chance it will be approved
in the 80's ?
UUCP: {ihnp4!scgvaxd!cadovax rutgers!marque}!gryphon!pnet02!richh
INET: richh@pnet02.cts.comeugene@pioneer.arpa (Eugene N. Miya) (03/25/88)
It occurred to me driving home last evening that ANSI X3J3 should have
published a "Rationale for the Changes to Fortran" similar to the "Rationale
for the Design of Ada(tm)." The "Ada Rationale" was (and is) quite widely
read and it explains a lot of thinking behind modern language design.
The problem with Fortran is the bulk of pre-existing code, but if, rather
than present pure synatx (and semantics), they had taken a bit more time to
explain the problems they were trying to address, I think a lot of grief
could have been minimized. This should have been done PRIOR to the actual
release of the draft proposed standard. Such a Rationale could have
addressed the problems of WHY depreciated features presented problems, as
well and suggestions for conversion, etc. The Standards document addresses
none of this, only specifies the form and the function. Anyway, next time.
From the Rock of Ages Home for Retired Hackers:
--eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA
"You trust the `reply' command with all those different mailers out there?"
"Send mail, avoid follow-ups. If enough, I'll summarize."
{uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugenechris@metavax.UUCP (Chris Collins ) (03/25/88)
In article <6415@ames.arpa> eugene@pioneer.UUCP (Eugene N. Miya) writes: >It occurred to me driving home last evening that ANSI X3J3 should have >published a "Rationale for the Changes to Fortran" similar to the "Rationale >for the Design of Ada(tm)." Here, here! This is exactly what I want to see. It's much easier to accept a decision when you know the reasons behind it. Then, you can give counter reasons, etc., but at least one round of the discussion is eliminated. Many times, all discussion is eliminated by the reason. For example, a macro language was discussed early in the X3J3 proceedings, but was not included in the current draft. In my email with a net and X3J3 member, it was excluded due to time constraints. I have no great problem with this IF I know this is the reason. ------ /MM/\MM\ META SYSTEMS, LTD. /MM/ \MM\ 315 E. Eisenhower /MM/ /\ \MM\ Suite 200 === == === Ann Arbor, MI 48108 \SS\ \/ /SS/ \SS\ /SS/ Chris Collins, Senior Programmer \SS\/SS/ ------ My colleagues chastised me for not saying these aren't my company's opinions. Companies don't have opinions.
eugene@eos.UUCP (Eugene Miya) (08/08/88)
In article <20931@beta.lanl.gov> dd@beta.lanl.gov (Dan Davison) writes: >As I said in my comments to the committee, nice language, too bad >it's not Fortran. >"I think, therefore I am confused" Great closing line! Anyways, Dan's comment makes we want to ask, "Well, what is Fortran?" An answer like "The standard" isn't want people want to here. Perhap compiler writers are doing the wrong thing? Perhaps we Should freeze F66 and develop new languages (F8X). Sorry, you have to keep your only IBM360 (using Level 2 OPT on the H compiler) it's the only thing running F66.... [I realize LANL does most major computing on Crays with very 360s.] We have to resolve this dusty deck problem. If the problem is pure compatibility, then we can never win. Not if users want performance increases, reliability increases, etc. I don't see users offering what they are willing to compromise. Should they prioritize what they are willing to give up in order to get added features they want? What is about Fortran which makes it what it is? What's Fortran-like? Don't ask me, I'm confused, too. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "Mailers?! HA!", "If my mail does not reach you, please accept my apology." {uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene "Send mail, avoid follow-ups. If enough, I'll summarize."
smryan@garth.UUCP (Steven Ryan) (08/09/88)
Didn't Backus say `I don't what language we'll be using in the year 2000, but it'll be called Fortran.'
lamson@sierra.uucp (scott h lamson) (08/10/88)
> eugene@eos.UUCP (Eugene Miya) wrote: >Anyways, Dan's comment makes we want to ask, "Well, what is Fortran?" I think Fortran is a user interface specification. I type " x= a+b print *,x " and a few magic steps later something happens. But if I type " x= a-b print *,x " something else happens. So Fortran is my user interface to control what all the hardware I never see actually does for me. That leads me to the conclusion that the most important aspect of Fortran is how well it fills the user interface requirement. Other criteria are that it uniquely specify what the user wants done (the end result more so than the intermediate steps), that it be compilable, that the resultant machine code be efficient. But the way I see it, how well Fortran interfaces with the user is first and most important. The other criteria are certainly significant, no question. >Perhaps we Should freeze F66 and develop new languages (F8X). I also wonder if we shouldn't more-or-less freeze Fortran-77 and use the proposed Fortran-8x standard (with the obsolescant features dropped immediately) as the basis for a new alternative scientific/engineering language (EFORT, evolutionary Fortran?) rather than trying to achieve a global comprimise. >We have to resolve this dusty deck problem. If the problem is >pure compatibility, then we can never win. There are computer scientists here with fortran -> Ada translators they have written. Certainly it seems feasible to me to provide filters which would remove obsolete features from dusty deck Fortran and replace them with more modern features as we learn more about how the Fortran user interface can be improved. Vendors who have extended Fortran-77 with non-standard extensions could provide filters to convert their extensions into newly standardized features. Then we can allow Fortran to evolve by adding new features which are judged to be important, keep the language manageable by dropping features which didn't work or have been replaced by improvements, and still preserve the investment in existing code. >What is about Fortran which makes it what it is? What's Fortran-like? Viewed as a user interface, Fortran supports concepts which make sense to its clientele: integer, real and complex numbers, vectors, matrices, functions, decomposition of complex problems, sequential problem solving (not encouraging for parallel processing I guess). Fortran, one hopes, would be a tool one uses to accomplish science/engineering computing with the least diversion from your primary purpose. With the memory management structure Fortran currently has (perfectly understandable given its ancestary), it seems hard to call the language an unqualified success in this regard. Scott| ARPA: lamson@ge-crd.arpa Lamson| UUCP: uunet!steinmetz!sierra!lamson (518)387-5795| GE DECnet: qtmvax::lamson
eugene@eos.UUCP (Eugene Miya) (08/12/88)
I draw several conclusions from what I had expected anyway.
1) The need to standardize on the front-end. Not just the syntax
of the language in some near worthless (just kidding) document.
[I'm just tired of FORTRAN IV FORTRAN V FORTRAN VII, insert your
favorite name progression] [Sorry, I'm going through this again with
three new machines]. This will then necessitate a standardized
intermediate language for the code generator. But the user need not
see this.
2) Okay, we should freeze the language and go on. And I can
unsubscribe from this new group and wait for the next language...... ;-)
Another person who suggested a Fortran Changes Rationale
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Send mail, avoid follow-ups. If enough, I'll summarize."dougs2@hcx9.SSD.HARRIS.COM (09/18/88)
I agree. It seems most of the radical changes to Fortran proposed in X3J3
can be placed in two categories:
o Those that make it easier for compiler writers
o Those that make Fortran a nice, simple, 'modern' language
One of the appeals of Fortran is that it is easily optimized. Since
there is no recursion, there is no stack to mess with. Variable space
may be allocated in the .text portion of the program. Simple variable
references are just that - simple. K=L is turned into move.l L,K rather
than move.l 4(sp),8(sp). Program flow maps are generally easier to
construct. Fortran is an easy language to write programs in. No counting
braces and semi-colons. I/O formatting that is straight-forward and
sensible (remember, these are only my opinions :->). It has signs of age,
but processes may be expressed simply, without much programming overhead.
It is too bad that Fortran is looked upon as a useless language by many
(just observe much of the recent flaming about Fortran vs. C for numerical
analysis). A book I came across in college, "Structured Fortran 77 for
Scientists and Engineers," puts major language features like EQUIVALENCE,
arithmetic IF, computed GO TO, EXTERNAL, and alternate RETURNs in an
appendix at the back, with the statement "the use of these features is
discouraged."
Douglas G. Scofield dougs@ssd.harris.com
Harris Computer Systems
2101 W. Cypress Creek Rd. Help stamp out AdaTran!
Ft. Lauderdale, FL 33309
These opinions are mine only.ok@quintus.uucp (Richard A. O'Keefe) (09/19/88)
In article <44400023@hcx9> dougs2@hcx9.SSD.HARRIS.COM writes: >I agree. It seems most of the radical changes to Fortran proposed in X3J3 >can be placed in two categories: > o Those that make it easier for compiler writers > o Those that make Fortran a nice, simple, 'modern' language Since all of Fortran 77 remains in 8X, none of the changes can make it easier for compiler writers. One of the main complaints about 8X was that it looked like making life rather hard for those unfortunates. There are a lot of nice things in 8X, but the conglomeration is not simple. >One of the appeals of Fortran is that it is easily optimized. Since >there is no recursion, there is no stack to mess with. Variable space >may be allocated in the .text portion of the program. Simple variable >references are just that - simple. K=L is turned into move.l L,K rather >than move.l 4(sp),8(sp). That is not true on all machines (e.g. IBM /370s and imitations, where K=L turns into L temp,Loffset(BaseReg) unless the compiler has been able to ST temp,Koffset(BaseReg) bind K or L to a register) and not necessarily an advantage on the machines where it is true. While I was appalled by the complexity of Fortran 8X (or is "frightened" a better term?) there were a lot of things I liked (long names, internal subroutines, dynamic arrays, things we had in Algol 60 (:-)). What is happening to 8X?