Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: What is the FORTRAN for ?
Message-ID: <60978@lanl.gov>
Date: 23 Aug 90 22:54:31 GMT
References: <13071@mentor.cc.purdue.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 41

From article <13071@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman):
> [...]
> The two examples I gave of incompatible Fortrans were both cases of
> vendor-supplied Fortrans that ran on the same machines and were reasonably
> compatible at the source language level (though with slightly different
> extensions), but which were fundamentally incompatible at the object code
> level.  They are definitely not callable from each other.  

I'll bet they _were_ callable from each other - it may have taken a
substantial bridge, but it could be done.  There is obviously no HLL
visible incompatibility between the _standard_ parts of the two
languages (the only parts that you can legitimately expect to be
call compatible anyway).

> [...]
> An implementor of some other language (Pascal, say) does not need to support
> every incompatible version of Fortran on the machine.  It's more cost-effective
> to pick just one Fortran to support.

However, supporting _all_ versions of Fortran is probably not much harder
than supporting one.  I would expect the first to be the hardest, each
one after would be easier.

Still, Pascal (ISO anyway) hasn't many high-level incompatibilities with
Fortran.  So the two languages should be mutually callable (if you stick
to data types they have in common).  The only case I would consider even
interesting (ie. slightly challenging) would be the fact that Pascal
multidimensional arrays are row-major while Fortran's are column-major.
This probably doesn't need conversion though - users can just transpose
the indices.

Now, if Pascal had introduced complex numbers and made a constraint that
such numbers _must_ be implemented as pairs of floating point values with
the imaginary part _first_ - then you'd have an incompatible design
feature.  That is what my original point was: a new language should not
introduce high-level features which directly conflict with the constraints
of the same feature in another popular language.  Not unless the new design
is specifically targeted for different users and nobody anticipates _ever_
mixing the two.

J. Giles