Path: utzoo!attcan!uunet!mailrus!iuvax!noose.ecn.purdue.edu!mentor.cc.purdue.edu!seaman.cc.purdue.edu!ags From: ags@seaman.cc.purdue.edu (Dave Seaman) Newsgroups: comp.lang.fortran Subject: Re: What is the FORTRAN for ? Message-ID: <13041@mentor.cc.purdue.edu> Date: 16 Aug 90 17:53:34 GMT References: <60202@lanl.gov> <13035@mentor.cc.purdue.edu> <1990Aug16.150718.15055@ux1.cso.uiuc.edu> Sender: news@mentor.cc.purdue.edu Reply-To: ags@seaman.cc.purdue.edu (Dave Seaman) Organization: Purdue University Lines: 27 In article <1990Aug16.150718.15055@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >In article <13035@mentor.cc.purdue.edu> ags@seaman.cc.purdue.edu (Dave Seaman) writes: >>But what if there is no vendor-supplied Fortran, and only third-party >>implementations exist? Do you say the first one to ship is the official >>version, and all others are barred from the market unless they change their >>interface to conform? >I would require that ANY language be compatible with the vendor's >standard calling convention - at least with a command-line switch. >Where the vendor's conventions is abysmally slow (i.e. VMS) I >would have an optional faster one. But what if there is more than one "vendor's standard calling convention?" For example, there was the CDC RUN compiler, which was later replaced by the incompatible FTN3/FTN4/FTN5 series. A more recent example is DEC Ultrix, which has the f77 compiler and also the incompatible VAX FORTRAN "fort" compiler (ported from VMS). If you take away either of those, you will alienate large numbers of users. When you start mixing languages, things get even more complicated. There may be a vendor's standard method for passing variables in Fortran, but that does not imply a vendor's standard method for sharing objects in higher-level languages. -- Dave Seaman ags@seaman.cc.purdue.edu