Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!aries!mcdonald From: mcdonald@aries.scs.uiuc.edu (Doug McDonald) Newsgroups: comp.lang.fortran Subject: Re: What is the FORTRAN for ? Message-ID: <1990Aug16.150718.15055@ux1.cso.uiuc.edu> Date: 16 Aug 90 15:07:18 GMT References: <60202@lanl.gov> <13035@mentor.cc.purdue.edu> Sender: usenet@ux1.cso.uiuc.edu (News) Reply-To: mcdonald@aries.scs.uiuc.edu (Doug McDonald) Organization: School of Chemical Sciences, Univ. of Illinois at Urbana-Champaign Lines: 32 In article <13035@mentor.cc.purdue.edu> ags@seaman.cc.purdue.edu (Dave Seaman) writes: >In article <60202@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>If >>I were designing a new HLL, I would make Fortran call compatibility a >>required part of the language specification. That is, if the target >>machine has a Fortran implementation, any conforming implementation of >>_my_ language would be required to be able to interface to it in a >>uniform manner. > >So what do you do if the target machine has more than one Fortran >implementation and the different versions are not even compatible with each >other? > >I suppose you could rule that the first Fortran implementation is the only one >allowed, thus ruling out improvements in the implementation that would change >the interface. > >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. In the PC marketplace, vendors that don't follow Microsoft's convention (i.e. Ryan=McFarland) get mercilessly bad press. Doug McDonald