Re: Sharing code and data in multi-language environments

|> [re interlanguage calling]
|> Therefore, possible research fields could be:
|>
|> - Linkers cooperating with compilers to enforce that kind of checking;
|> - Utilities translating interfaces from one language to another;
|> - Formalisms describing data, types, routine profiles, calling mechanisms,
|> parameter passing and so on independently from any particular language;


Well, it seems more like an implementation issue than a research issue.
There are quite a number of multi-language environments, including
Symbolics (CommonLisp, C, Fortran, Prolog), Poplog (Pop-11, CommonLisp,
SML, Prolog), Harlequin (CommonLisp, SML, Prolog(?)), and many others.
Intercalling and linking between FORTRAN, C, and C++ is quite common, and
C++ even has some minimal language support for interfacing with C code.
CommonLisp implementations routinely offer "foreign function interfaces",
usually to C and FORTRAN.


Efforts at making such interfaces safe and automatic are somewhat hampered
by the fact that most people want to interface with existing FORTRAN and C
libraries (often available only in binary), and those just happen to be
two languages for which many implementations include neither compile-time
nor run-time type or array bounds information, making any attempt at safe
interfaces pretty futile--you can't verify information that isn't there.


In fact, C is a particularly bad offender, since the concept of "pointer"
subsumes what is called an "array", a "displaced array", a "locative",
"call by reference", and a "heap object" in other languages. That means
that statically, there is little that even the most sophisticated foreign
function interface can do to help you, and that dynamically, any such
verification would be quite costly and completely incompatible with
existing C implementations.


I recall that there has been some work on documented, vendor-independent
and language-independent representations (as opposed to the ad-hoc
solutions that individual vendors adopt), but I suspect that for anything
other than RPC and file I/O (using, for example, SunRPC and XDR), people
are probably not willing to pay the overhead, and the work that I have
seen was heavily biased towards a Pascal-ish view of the universe.


Another solution that has been adopted is to write code that parses
interface definitions from some language (usually, ".h" files in C) and
generates the right foreign-function declarations for a particular target
language (say, in CommonLisp or SML).


You can take this one step further and actually simply translate the
source language, into the language you are trying to interface with.
People have begun to take that approach to interfacing C/FORTRAN with
CommonLisp.


So, altogether, I think there is great room for improvement, although I
think it's mostly on the practical/political side. Abandoning C-style
interfaces (in favor of something more descriptive) would probably be the
greatest step forward, and the hardest to achieve, given the current
predominance of C/C++ in the market. Still, there is a glimmer of hope:
the "safe subset" proposal by Ellis and Detlefs goes a long way towards
making C++ interfaces sufficiently descriptive to interface automatically
with "normal" programming languages.


Thomas.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.