riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (10/31/88)
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: >>why would CERN, the European particle accelerator establishment, want >>to throw away all that code? >As long as they have a compiler for F77, and whatever new language they >are using will let them mix F77 routines with Utopia-99, why would they >_have_ to throw away all that code? Mixing languages in a portable manner is very difficult to do in a multi-vendor environment, where the lifetime of the code is often far longer than the lifetime of any given cpu. I can mix languages easily on our VAX; with a little more effort, I could probably do so in a manner compatible with Apollo, Sun, etc. Whatever I do, it's almost guaranteed not to work on the IBM mainframes. And our computer acquisition committee would be very reluctant to restrict all future computer purchases to vendors with compatible cross-language calling support. Until there is a a well supported standard for mixing different languages, mixed language development is not a viable alternative to a new Fortran standard in a high-energy physics (e.g. CERN) research environment. (Personally I'd love to write the occasional routine in C, but our Software czar would kill me if I tried...) -Dan Riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet) -Wilson Lab, Cornell U.
ok@quintus.uucp (Richard A. O'Keefe) (10/31/88)
In article <6717@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) 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: >>>why would CERN, the European particle accelerator establishment, want >>>to throw away all that code? >>As long as they have a compiler for F77, and whatever new language they >>are using will let them mix F77 routines with Utopia-99, why would they >>_have_ to throw away all that code? >Mixing languages in a portable manner is very difficult to do in a >multi-vendor environment, ... Whatever I do, it's almost guaranteed >not to work on the IBM mainframes. (Recall that I'm not suggesting that F8x be abandoned, merely supporting the claim that it would have made sense to keep F77 and invent a new language instead.) This argument is bogus. You don't need a general anything-to-anything standard. All you need in order to preserve your investment in F77 code is a F77-to-Utopia interface standard. There is no reason why the Utopia standard couldn't say "F77 common blocks can be accessed by the following construct ...; a F77 program unit can be accessed by using the following interface declaration ...." In effect, this is what F8x _already_ does. F8x introduces things like recursive subprograms, programmer-defined data types and parametric types which can used to declare arguments, & so on. I do not expect F8x compilers to use the same linkage conventions as old F77 compilers. But there is no reason that they couldn't generate the right code to call F77 routines. (The dpANS C standard does this for C; functions without prototypes in scope have to be called the "old" way.) I imagine that F8x compilers on several machines will provide this as an extension anyway, to protect the investment of people using those machines who have written code in other languages and provided F77 interfaces. Or how about people who have bought _binary_ licences for subroutine libraries and need to use them _now_ before the library vendor gets around to recompiling with F8x? Let me just take that last point out again and emphasise it: there will be a conversion period during which sites having object licences for F77-compatible libraries (most of which will have been written in F77) will want to use these libraries with F8x, but a F8x-compatible versions may not be available from the vendor, or may not be cheap. (Think of someone who has bought a GKS package, for example.) It will thus be a practical necessity for F8x compiler writers to provide some way of calling separate subprograms which expect an F77 interface. This wasn't much of an issue with F77, because F77 didn't add much to subroutines. (It was already legal to pass Hollerith constants to subprograms in F66.)