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: <60344@lanl.gov>
Date: 16 Aug 90 23:09:46 GMT
References: <13035@mentor.cc.purdue.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 43

From article <13035@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman):
> In article <60202@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>>If
>>I were designing a new HLL, I would make Fortran call compatibility a
>>required part of the language specification.  That is, if the target
>>machine has a Fortran implementation, any conforming implementation of
>>_my_ language would be required to be able to interface to it in a
>>uniform manner.  
> 
> So what do you do if the target machine has more than one Fortran
> implementation and the different versions are not even compatible with each
> other?

I'm not interested in whether the Fortrans (or Cs, Pascals, Modulas,
etc.) are compatible with each other, I only want them to be _callable_
from each other on a way which appears consistent from the HLL point of
view.  If this means that several different bridges to Fortran have to
be present on the low-level for different Fortrans, that tough.  Of
course, implementors who avoid use of industry (or vendor) standard
calling sequence conventions are shooting themselves in the foot by
making their produce harder to use from within existing environments.

This is all beside the point that I was making.  That is, there should
be no _high_level_ impediments to mixing code (like incompatibilities
of common data types where is difference is visible at the high level).
An example of this is character variables in Fortran an C.  Both
languages have fixed sized character variables but C provides a set of
routines which expect null termination on all strings.  The use of this
null termination is so common in C that people think of the null as a
required part of the C character value (in fact, the C character
constant constructor (quote marks) puts the null on automatically).
Cramming this null onto full Fortran variables is the problem most
people refer to when they consider the problem of Fortran/C character
compatibility.

Note: it is not only not _necessary_ to add null termination, but it is
actually _more_ efficient _not_ to use null termination and to carry the
present active length of a string around explicitly instead.  In C this
would require the use of the mem???() functions (ie. memcmp(), memcpy(),
etc.) instead of the str???() functions.  In Fortran, this is already
what most people do (using more convenient - built-in - constructs).

J. Giles