Path: utzoo!utgpu!news-server.csri.toronto.edu!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: <61409@lanl.gov>
Date: 28 Aug 90 22:20:33 GMT
References: <13393@mentor.cc.purdue.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 112

From article <13393@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman):
> [...]
>                                            I can understand wanting
> to call Fortran routines from a Pascal program, but what is the
> point in trying to call one Fortran from another, especially when
> they are wildly incompatible?  Isn't it easier just to recompile
> everything using a single compiler?  

If you have that attitude, you must have had better luck converting
code between compilers than I have.  Even compiler which are _meant_
to have the same functionality often don't.  On the Cray, switching
between CFT and CFT77 is not a simple task.  It is useful to do this
conversion in an evolutionary way - changing a few routines or sets
of routines at a time and linking the results together.

Further, two different implementations may provide different extensions.
I may want to have access to those extensions of _both_ from within
a single program.

> [...]
> My point in introducing the two-incompatible-Fortran examples was
> that you can't solve all the incompatibility problems by requiring
> all languages to be compatible with the vendor-supplied Fortran on
> the machine, [...]

I didn't recomment that.  In fact, I think it would be silly to
require all languages to be compatible with the vendor.  After all,
what if the vendor implementation was _really_ bad?  I said that
new implementations should have the _option_ of producing compatible
_calls_ if the user chooses.

> [...]        because there may be more than one vendor-supplied
> Fortran, and they may be incompatible.  [...]

This looks like time to point out the user's option of staying away
from the products of such inconsiderate vendors.  Even so, new
implementations could simply produce the _two_ options - one for
each vendor implementation.

> [...]     Beyond the requirement that LOGICAL variables take the
> same amount of storage as INTEGER and REAL variables, the standard
> places no restrictions on the internal representation and there is
> no single "best" way to implement the type.  [...]

You are still hung-up on the "all or nothing" syndrome.  If logicals
are different on two implementations, the bridges will have to alter
the values on the way through.  But, even without such sophistication,
codes which don't pass logical parameters could still be shared.  This
is a significant number of codes.

The issue of compatibility between languages/implementations is obviously
not either/or.  Clearly, the less compatible two implementations are, the
less the user of one will be likely to want to switch to or share code
with the other.  If a new implementation is incompatible with an old one,
then the vendor of the new product obviously doesn't want or need the
business of users who already have the older implementation.

However, this discussion was originally about language _design_ not
implementation.  If a new _language_ is fundamentally incompatible
with the popular old ones - regardless of how either are implemented -
then the designer of the new must really think that users of the old
will _never_ be temped to switch: so he didn't bother thinking about
them.

> [...]
> You misunderstood.  The situation I described can arise within the
> same implementation when modules are used, but modules are not a
> part of pre-1990 standard Fortran, which is what we have been
> discussing.  One of my examples was Fortran 77; the other was
> Fortran 66.
> 
> There is no mechanism in Fortran without modules for a user even
> to force multiple routines by the same name to be loaded; [...]

Nonsense.  We have done just exactly that for years.  Modules are
a mechanism for defining the scope of global data items (common blocks,
and subroutines in Fortran).  As such, they are completely implementable
in the _loader_ (after all, that's the only tool that implements the
scope rules of globals).

So, make your library builder so that it can tag libraries (or subsets
of libraries) as modules.  The scope and referencing of these modules
can then be given at load time through loader directives.  To be sure,
this is less convenient than having the scoping described explicitly
in the source code - but it has the same capability.

Note: the CTSS Cray loader has been able to do some of this for many
years.  Long before Modula (or various modular Pascals for that matter),
I recommended that the full equivalent of modules be put into out loader.
Multiple routines with the same name have been possible in our loader
since before I came to the lab.

> [...]
>>However, if you want to discuss this topic, I have a solution to propose.
>>Add 'module' support to your languages (as from Modula).  
> 
> And I suppose you think adding modules to an implementation that
> was designed without modules in mind will not take man-years of
> reprogramming?  

Not for the _users_.  Implementors, on the other hand, would have a
valuable product on their hands if they did this - so they shouldn't
grudge the man-years either.

By the way, putting it into the loader - even a loader _much_ more
powerful and sophisticated than is usual for UNIX - is about _one_ man
year.  I know - I provide local site support for the CTSS Cray loader
and that is my estimate of the effort to install the feature here.  We
already _have_ the capability to load routines with duplicate names
and link them to their proper calls.

J. Giles