Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: What is the FORTRAN for ?
Message-ID: <61533@lanl.gov>
Date: 29 Aug 90 20:36:22 GMT
References: <13441@mentor.cc.purdue.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 69

From article <13441@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman):
> [...]
> My mistake.  I meant to say, "no mechanism in STANDARD Fortran."

Yes, but what you _did_ say was "no mechanism" - period.

> [...]                                                       I have been
> noticing for some time that you always exclude extensions when they are
> inconvenient for your position, but you are quick to include them when you
> see an advantage.  You even ruled out extensions earlier in this thread,
> when you thought I might be about mention some.

That is because I make a distinction between the _definition_ of a
language and the _implementation_ of it on a particular machine.  I can
understand why C proponents can't understand such a distinction - until
this January their language didn't _have_ a definition: only a set of
implementations.  If we are talking about the language _definition_ (as we
were previously doing), I would indeed rule out discussion of extensions.
As we are presently discussing _implementations_ (and not even of the
language), I feel justified in pointing out that implementations exist
that that _DON'T_ require language extensions but _DO_ allow the same
features as modules provide.  I even pointed out _explicitly_ in may last
posting that what I was proposing would require modification to the
language only for convenience.

By the way, I thought it was quite clear in the context of this discussion
that we were talking about the implementation of the language environment
- not even the languages themselves.  It is obvious that calling one
language from another is not part of the _definition_ of any existing
standardized language (although, it is my contention that maybe it should
be for some).  It is also clear (and I have pointed it out) that the
languages could be extended to provide this capability (modules and giving
language attributes to external declarations come to mind).  Such changes
to the language have a convenience value, but are not necessary.  You can
achieve the desired result without using the languages themselves in
non-standard ways.

Indeed, the only extensions that I have excluded from this discussion are
attempts to claim that calling between two Fortrans is impossible because
they might each have different extended data types.  It is not even clear
to me the _meaning_ of calling (say) a QUATERNION valued function from a
Fortran that doesn't have quaternions.  This is true of any mixed language
calls - you can't expect to pass arguments or results with types that one
of the languages doesn't have. (Even in this case though, the ability to
call between languages can be exploited by the user.  A _user_ written
bridge (in addition to any automatic one) could provide a means for the
languages to communicate values of the unusual data types.  For example,
QUATERNION could be represented as an array of 4 reals.  But, the user
can't do this unless he first has the ability to call between the
languages using the data types that they both share.)

Calls between languages using data types that they both share is obviously
possible.  It can be done automatically - even when the internal represen-
tations differ.  The loader (or some pre- or post-loader tool) knows what
language each routine is written in, it _can_ know the internal represen-
tations of all the data types in each language, it knows the types of
arguments and of function results, it can therefore automatically bridge.
There are probably more efficient ways of doing this conversion, but this
is at least possible.  It also points out the negative value of gratuitous
differences between languages and implementations - the fewer and simpler
the differences in internal representations, the simpler the process of
building a bridge.

Finally, as I keep pointing out, this is not an either/or issue.  _ANY_
ability of two languages or implementations to communicate with each other
is probably an advantage to both.  The more fluently and flexibly they
can call one another the better.

J. Giles