Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdcad!sun!pitstop!sundc!seismo!uunet!convex!mozart!psmith From: psmith@mozart.uucp (Presley Smith) Newsgroups: comp.lang.fortran Subject: Re: Why have FORTRAN 8x at all? Keywords: FORTRAN PL/I kludge Message-ID: <684@convex.UUCP> Date: 30 Oct 88 14:53:33 GMT References: <388@ubbpc.UUCP> <16187@agate.BERKELEY.EDU> <599@quintus.UUCP> <75320@sun.uucp> Sender: news@convex.UUCP Reply-To: psmith@convex.com (Presley Smith) Organization: Convex Computer Corporation, Richardson, Tx. Lines: 102 In article <75320@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: >In article <599@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>In article <16187@agate.BERKELEY.EDU> link@sag4.ssl.berkeley.edu (Richard Link) writes: >>>In article <388@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: >>>>why is there an effort to make up a new standard at all? >>> >>>The reason for a new standard is: >>>(1) there is a huge investment in already written code > >>But the *old* standard is sufficient to protect that. > >Nonsense. If I can't use the tools developed in the "old language", I >have to rewrite them in the new langauge. This is not protecting an investment. >> >>>(2) FORTRAN is the most useful (existing) language for number crunching. >>Again, the *old* standard is sufficient to protect that (if true). > >(if true ?) sheer number of lines of code produced each year, combined >with the constant research into better fortran optimization techniques >would seem to demonstrate this. Know of a single vendor of high >performance computers who doesn't produce a fortran compiler FIRST ? > >btw: ditto on the failure of the old standard to protect the future The mixture of old and new features will provide new challenges for the vendors that must optimize code. The new standard has certainly NOT been written with optimization in mind. One of the foremost researchers in Fortran optimization told me last year that he should be FOR the proposed new language because it would keep him busy for the next few years consuting with compiler writers on the problems with optimizing the new constructs. He was against the proposal because he did not see the real benefit to the Fortran community. (Text deleted) >> >>Just how hard it will be to compile F8X I don't know. >>All I can say is that I know several dozen programming languages, including >>APL and DAP FORTRAN, and the Feburary '87 draft of F8x described a language >>that I found bewilderingly complex. I liked most of the new features, it >>was just that they had been bodged together in the most apalling way so that >>the new language could claim F77 as a subset. We can be reasonably >>confident that for three to five years after the standard is settled the >>new compilers will be sufficiently buggy that you will have to rewrite your >>old code to use the new features (because those will be the bits that work!). >>Unless, of course, you hang on to your old compilers until the new ones >>settle down. That's what keeps happening with COBOL: some of the COBOL >>programmers I know didn't switch over to COBOL 74 until in the 80s because >>not only were the compilers buggy, but there turned out to be one or two >>serious ambiguities in the standard which different compiler writers had >>in good faith interpreted different ways. > >The new language is constructed such that most users will simply not >have to know how to use it (like how to write code with keyword >arguement passing and operator overloading). Those experts tasked to >create easy to use libraries need these features, and these features >make it simpler for naive users to write new code. > One of the major things that IBM complained about in their ballot was that proper use of Fortran 8x would not preserve the investment in user training. As has been noted, it is a complex language and users will have to be trained to use it and use it properly. There will be a mixing of old and new constructs so that programs that people have worked with for years will change in ways that programmers will have to get used. This mixture of constructs will cause problems in sustaining code. I'm not sure what "experts" you expect are going to create these libraries, etc. It will take years for such facilities to become widespread and since they will NOT be defined by a standard, people who use them will find their code is no longer portable. I don't believe that Fortran 8x will every make it "simpler for naive users to write new code." That's like saying it's easy for the naive user to write new code in Ada because a lot of packages have been defined... it's just not true. >Your holding up COBOL as an example is a good point, as old COBOL code >cannot always run on new compilers. By construction this is not true >of F88. Thus whenever a user switches over the cost of switching is low. > One of the major debates in the X3J3 committee today is whether to start with FORTRAN 77 as a base document and add the 8x constructs to produce the next version of 8x for public review, or to start with the current version of 8x and remove and modify portions to respond to public review. Why this debate? Because so much has been changed in the proposed 8x that there are members of the committee that are NOT convinced that all of FORTRAN 77 has been preserved. They claim that the only way at this point to insure that 8x is really upwardly compatible with FORTRAN 77 is to start with FORTRAN 77 and re-add and integrate the 8x features back into it. These members of X3J3 don't believe that there has been enough effort to insure that FORTRAN 77 has not been changed in the process of trippling the size of the FORTRAN 77 document to produce the 8x document. Just as with the arguments on COBOL, there will be different vendor interpretation of Fortran 8x that will cause problems with portability. Since no one has implemented at 8x today, we currently don't even know where those problems will occur. (Text deleted)