Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: What is the FORTRAN for ?
Message-ID: <61279@lanl.gov>
Date: 27 Aug 90 22:09:19 GMT
References: <13293@mentor.cc.purdue.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 59

From article <13293@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman):
> [...]
> 	1.  cause all subroutine/function calls to be routed through a bridge
> 	    routine that would examine the argument lists and transform them,
> 	    when necessary, into the form expected by the called routine, and

Doesn't _have_ to be the loader.  Many implementations have the
capability to do this sort of thing in the compiler.  Some Pascals,
for example, have a way of declaring a routine to be a Fortran
external.  If there were several different Fortrans on the target
machine, there is not reason not to have a distinct way of declaring
each.

On the other hand, the "smarts" could be built into a loader which
would relieve the compiler writer from the need to do all this and
place the call sequence compatibility problem into a single tool for
all language implementations to use.

> [...]
> 	2.  transform all I/O requests to the nonresident I/O system (the one
> 	    not initialized by the main program) into the equivalent call in
> 	    the other system (which would probably require an extensive table
> 	    of routines to watch for, and specially-written library routines to
> 	    do the equivalent in the other I/O system, since there is no 1-1
> 	    correspondence between the two), and

This is a different issue from call sequence compatibility.  What you
are implying is that unless you can successfully do I/O from both of
the two languages/implementations, it is never worth trying to mix the
two.  However, the _vast_ majority of mixed language usage is not of
this form.  If I have (say) a Fortran Runge-Kutta routine that I want
to use from Pascal, I don't want to have to rewrite the thing, I want
to just call it.  Call sequence compatibility is not _everything_, but
it _is_ a valuable capability.

Even so, it is usually not all _that_ hard to do I/O from both languages.
To be sure, it is not simple.  But, it's not "man-years" of effort either.

> [...]
> 	3.  resolve name conflicts at load time caused by different routines
> 	    being loaded from different libraries with the same name but
> 	    different functions,

This clearly doesn't have _anything_ to do with the subject we are
discussing.  This problem can arise even if all the libraries and
main codes are writen in the _same_ language and for the _same_
implementation.

However, if you want to discuss this topic, I have a solution to propose.
Add 'module' support to your languages (as from Modula).  Then, each
different library can be compiled as a separate module.  The linker
can avoid conflicts because it knows that routines in different modules
are different - even if they have the same name.  The default libraries
for a given implementation are 'automatically' referenced modules for
code compiled with that implementation.  Except for synchronization
problems (I/O to the same file from distinct languages), this solution
even fixes the problem cited in point <2> above.

J. Giles