mccalpin@masig1.stars.flab.Fujitsu.JUNET (John D. McCalpin) (06/18/89)
I'm sure that DEC will keep the current compiler technology available for a _long_ time after the F8X standard is adopted. In fact, some vendors may not even bother with implementing the new compiler at all. One vendor (who shall remain nameless) said that his company was willing to change their NO vote to YES if ANSI would keep the 77 standard active -- thereby defining F8X to be a new language, and allowing F77 to still be an "official" fortran. It took IBM long enough to come out with a Fortran-77 compiler -- it will be interesting to see how long a Fortran-88 compiler takes.... Maybe the new standard will mean the end of Fortran portability, rather than an improvement.... -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu - mccalpin@nu.cs.fsu.edu
mccalpin@masig1.ocean.fsu.edu (John D. McCalpin) (06/19/89)
Sorry about the header on the previous message -- this one should make more sense, since I do not work for Fujitsu, or live in Japan.... -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu - mccalpin@nu.cs.fsu.edu
CEReid@cup.portal.com (Curtis E Reid) (07/22/89)
There was an article on the front page of DIGITAL REVIEW this week that said VAX FORTRAN will break under F88 if implemented. The F88 Standards has been adopted against DEC's wishes and codes that uses VAX Extensions extensively will break under F88. Is this true? I have a lot of source codes that made extensive use of VAX Extensions. Will these codes have to be modified to F77 so it will be compatible with F88 when it comes out? Or, should I start looking at other languages? Curtis
khb@chiba.Sun.COM (chiba) (07/23/89)
In article <19553@cup.portal.com> CEReid@cup.portal.com (Curtis E Reid) writes: >There was an article on the front page of DIGITAL REVIEW this week that said >VAX FORTRAN will break under F88 if implemented. The F88 Standards has been >adopted against DEC's wishes and codes that uses VAX Extensions extensively >will break under F88. > >Is this true? I have a lot of source codes that made extensive use of VAX >Extensions. Will these codes have to be modified to F77 so it will be >compatible with F88 when it comes out? Or, should I start looking at other >languages? DEC has strongly asserted that F88 will be incompatible with their extended Fortran. Many other vendors think that the problems are not insurmountable. (note the commitee vote 31-10, if memory serves. Certainly not all members are vendors; but not all user delegetes voted yes either). If your application domain is "scientific" then I would advise you to stick with Fortran. If DEC doesn't support you well, there will be vendors who will. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
bam@bnlux0.bnl.gov (Bruce Martin) (08/03/89)
In article <19553@cup.portal.com>, CEReid@cup.portal.com (Curtis E Reid) writes: > Is this true? I have a lot of source codes that made extensive use of VAX > Extensions. Will these codes have to be modified to F77 so it will be > compatible with F88 when it comes out? Or, should I start looking at other > languages? To: CEReid@cup.portal.com Subject: Re: Digital Review Article: VAX Fortran will break under F88 In-reply-to: your article <19553@cup.portal.com> News-Path: sharkey!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!rochester!rit!tropix!moscom!ur-valhalla!uhura.cc.rochester.edu!sunybcs!rutgers!cs.utexas.edu!uunet!portal!cup.portal.com!CEReid All codes that use vendor-parochial extensions will break when a standard is revised. Even if the standard is upward-compatible (i.e. extensions only & no deletions, as is the case with Fortran-88). The reason has nothing to do with the standard itself. It is simply that, since the new standard has new features, the vendor usually figures that this is good time to write a new compiler (or massively revise the old one). This, IN TURN, usually seems to the vendor like a golden opportunity to DROP SUPPORT for some of his own extensions, without taking all the blame from his customers. {Note that this is totally independent of whether or not a vendor's existing extension can coexist with the new extensions proposed for the standard. Rarely does a new standard unintentionally invalidate the vendor's extension. Any vendor that wished to continue supporting an extension would find it VERY, VERY easy to convince a standards committee to use a different syntax for a conflicting extension to the standard, so that the two could co-exist. (I've seen it happen. Nobody wants to be accused of hurting one particular vendor.) In short, the reason a vendor drops support for an existing extension has nothing whatever to do with the syntax and semantics described by the new standard!} The bitter lesson some users and managers never seem to learn is that the use of ANY vendor extension (to ANY language) involves very serious risks and can have great impact upon the life-cycle cost of the code. (Sadly, however, developers often escape the blame.) Generally, the resultant code will not run on any other vendor's machine, will not even run on the same hardware under a different operating system (like ULTRIX!), and perhaps, at some future date, may not be able to run on any existing machine or system. Except for those which can be mechanically translated (like trailing comments, for instance), vendor extensions are a snare and a delusion. The value of a higher-level code is inversely proportional to the number of systems and machine architectures on which it cannot run correctly. The return on investment for software engineering efforts drops precipitously if coders are permitted to freely use that tempting stuff that appears with shaded background (or whatever) in the vendor reference manual. (The fact that the coder did not learn it in school also adds to the appeal!) Vendor extensions to language standards are probably the most brilliant marketing gimmick ever invented by the IBM (Incredibly Brilliant Marketing?) Corporation, altho DEC (Don't Ever Cooperate?) probably exploits this nasty trap much more effectively. Of course, the standardization process is ridiculously slow, is otherwise faulty, and needs a swift kick in the pants. Swiftly!. Nevertheless, that's a insufficient reason to allow the investment of software engineering effort into something that may become useless if the marriage between your company and its hardware vendor ever breaks up. Bruce A. Martin DISCLAIMER: The opinions stated above do not necessarily reflect those of my wife, the Grumman Corporation, Polytechnic University, BNL, DOE, DoD, ACM, BSA, APO, the United States of America, the Libertarian Party, Ron Paul, the Ayatolla Khomeni, or any other person or organization, real or fictional, which I have included or omitted intentionally or unintentionally.