Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!purdue!i.cc.purdue.edu!j.cc.purdue.edu!mace.cc.purdue.edu!tsh From: tsh@mace.cc.purdue.edu (Greg Kamer) Newsgroups: comp.lang.fortran Subject: Re: FORTRAN 8x parser/lexer .NE. compil Message-ID: <909@mace.cc.purdue.edu> Date: 24 Oct 88 16:25:39 GMT Article-I.D.: mace.909 References: <656@convex.UUCP> <44400026@hcx2> Organization: Purdue University Lines: 84 > > On the other hand, I think Steve is right on track with his concerns > > about the cost of optimizing/vectorizing the array language. If most of > > the opponents of the Fortran 8x draft were expressing concerns about the > > amount of effort to generate efficient code for the array language, I > > could take their concerns about complexity more seriously. Instead, I > > see most of those opponents supporting the array language and a number of > > vendors already implementing it. > Well I, for one, have been expressing concerns about the array language. > I think it will cause scalar machines particularly to run like molasses > in Alaska. Why? I am afraid this doesn't make any sense to me at all. Our vector code has been ported to a LOT of scaler machines, and the only degradation seen was that expected from the lack of vector hardware and differences in scaler processing speed. Please give an example- I'm afraid that after working with a vector machine for 5 years I can't think of any. > So why, you ask, am I supporting the array language? I am > supporting the CONCEPT of the array language, but I have real problems > with some of the details. I think there are so many users who are > running, or would like to run, the same code on both supercomputers > and scalar machines (even PCs!), that some kind of array language is > a must for portability. I would like, however, to see it scaled > back somewhat from the 8x draft. > The reason that I, and I suspect others, have not harped on the array > language is because we recognize its importance. The fact, though, > that the array language adds significant complexity makes us all the > more reluctant to accept much else. Its like a young couple buying > their first house: they recognize they _need_ a house, but it doesn't > have to have gold-plated fixtures. We simply can't afford the effort > required for the 8x array language AND all the other stuff too. The good news is that there is SOME vector syntax as part of the standard- the bad news is that it is pretty simplistic compared to the already available toys in CDC and Cray vector Fortran. The inability to easily port these programs costs us EASILY 30 to 40 thou a year in conversion and update costs. We need this stuff and we need it NOW! If you are going to take 4 or 5 years to develop a standard and another 4 or 5 to implement it, you better believe you want the gold-plated fur-lined version and not the economy model. Keep in mind that the cost of writing compilers is miniscule compared to the cost of using an inadequate one. If Fortran 88 follows that same cycle as Fortran 66 and Fortran 77 in terms of standard development / implementation / dissemination / acceptance I think we can realistically expect to see such a compiler in about 1993 on those machines where people are willing to pay the $$$ for writing good compilers, and we might see it in widespread use by maybe 1996 to 1998. I am not willing to wait until the next CENTURY to see the non-vector Fortran 88 extensions. When a compiler writer points out a feature of Fortran 88 that will be impossible to implement, and if enough compiler writers agree, it ought to be deleted or modified. Otherwise, the "excessive" amounts of time some people claim it will take to implement the new standard need to be measured against the REALLY excessive waste of human time that will result from using a "simple" compiler for the next 15 years. ... > Exactly, you say! So how come INCLUDE is better, you shout? The > difference is that the user _knows_ that INCLUDE is just that, an included > file, but MODULEs get compiled! INCLUDE files never get compiled, so there > is no expectation from the user that such recompilation will fix all the > references, or at least tell him he screwed up. The opposite is true for > MODULEs; the user expects that the compiler will remember that the MODULE > was recompiled, and tell him if something else needs to be recompiled. > Also, remember that by the time 8x is out, lots of people will have had > experience with Ada, and that will color their expectations. I've written about this one before. MODULE is much more useful than INCLUDE if you are writing your code on a front-end machine and submitting it to a remote host. For such a setup, INCLUDE's have to be done with a front-end preprocessor before submitting the mainframe. With MODULE's you can simply prepend all of your MODULE's to the front of the code and send it off. Put simply, making INCLUDE part of the Fortran 88 standard does me absolutely no good at all- MODULES will allow me to get rid of the preprocessor I currently have to use. -- Greg Kamer - Purdue Macromolecular Crystallography tsh@mace.cc.purdue.edu (internet - read every day) xtsh@purccvm.bitnet (bitnet - read very rarely)