[comp.lang.fortran] Digital Review Article: VAX Fortran will break under F88

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.