Language interoperability

[patl]

Hi all,

Over the last couple of months, I've been slowly working on a
prototype for a
C-language library that allows calling into different languages via
plugins.
The goal is to present a somewhat "universal" interface for different
languages.
Here is a quick example (omitting error checking and some cleanup):

mlp_context *ctx = mlp_context_new() ;
mlp_language *lang = mlp_language_init(ctx, "perl") ;
mlp_runtime *rt = mlp_runtime_new(ctx, lang) ;

const char *class = "calc" ;
mlp_value *v = mlp_object_new(ctx, rt, class, NULL, 0, NULL) ;
mlp_object *obj = mlp_value_take_object(v) ;
mlp_value_delete(ctx, v) ;

mlp_value **args = mlp_value_array_new(2) ;
args[0] = mlp_value_new_long(1) ;
args[1] = mlp_value_new_long(2) ;
mlp_value *v2 = mlp_object_call_method(ctx, rt, obj, "add", args, 2,
NULL) ;
long ans = mlp_value_get_long(v2) ; /* 3 */

This code calls the following perl code:

package calc ;
sub new {
my $class = shift ;

my $this = {} ;
bless($this, $class) ;

return $this ;
}

sub add {
my ($this, $a, $b) = @_ ;

return $a + $b ;
}

but it can also call the following Java code, simply by changing
"perl" to "java"
in the second line:

public class calc {
public calc(){
}

public long add(long a, long b){
return a + b ;
}
}

The bigger idea is to make language interoperability easier by only
having to
develop interaces to this library instead of having to develop
interfaces to every
other language.

So my questions are:

- Do anyone know of other similar projects (currently maintained or
not)?
- Any research or papers related to this that may be useful?
- Any comments/suggestions?

Thanks,

Patrick

[Robbert Haarman]

Hi Patrick,

On Sat, Nov 28, 2009 at 02:13:07PM -0800, patl wrote:
>
> So my questions are:
>
> - Do anyone know of other similar projects (currently maintained or
> not)?

The first thing that comes to mind is SWIG: http://www.swig.org/

If I understand you right, SWIG goes the other way: it allows programs
written in various other languages to call C and C++ functions.

Calling functions defined in another language from C is often provided
as a feature of the language implementation. For example, the Ruby
1.8 interpreter can be instantiated from a C program, and various C
functions can then be used to perform tasks that are normally performed
by Ruby code, including calling Ruby methods.

Many language implementations come with a foreign function interface
that allows C functions to be called from the programming language,
and often also programming language functions to be called from C (i.e.
the FFI goes both ways).

Other things that come to mind are Microsoft's Common Language Runtime,
the Parrot virtual machine, and similar efforts creating a common
infrastructure and object protocol that multiple languages can use,
thus enabling programs in one language to call functions implemented
in another language.

In a more primitive form, this also exists in various ABIs (which, however,
tend to be followed by C and C++ and not much else) and in Unix's
exec family of system calls, which allow, for example, C programs to
call shell scripts which can, in turn, call C programs.

Regards,

Bob

--
When Marriage is Outlawed, Only Outlaws will have Inlaws.

[Dmitry A. Kazakov]

On Sat, 28 Nov 2009 23:56:32 +0100, Robbert Haarman wrote:

> Calling functions defined in another language from C is often provided
> as a feature of the language implementation. For example, the Ruby
> 1.8 interpreter can be instantiated from a C program, and various C
> functions can then be used to perform tasks that are normally performed
> by Ruby code, including calling Ruby methods.
>
> Many language implementations come with a foreign function interface
> that allows C functions to be called from the programming language,
> and often also programming language functions to be called from C (i.e.
> the FFI goes both ways).

Both are basically same, provided the language supports foreign function
interface in a systematic way. E.g. in Ada there is a pragma Convention
that determines the interface of a declared subprogram or object. If that
has, say, the FORTRAN convention then being imported it can be used to
call/refer something from a FORTRAN library, while being exported it can be
called from FORTRAN (like a callback), or as an object passed as a
parameter to FORTRAN).

It is probably necessary to mention run-time library issues. A language may
have a non-trivial RTL, which might require certain initialization, and
often be conflicting with the RTLs of other languages. The potential
problems include:

1. I/O support
2. Tasking support
3. Dispatching tables
4. Heap management and GC
5. Exception handling (especially across language boundaries)

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Marco van de Voort]

On 2009-11-28, patl <patrick.le...@gmail.com> wrote:
>
> So my questions are:
>
> - Do anyone know of other similar projects (currently maintained or
> not)?
> - Any research or papers related to this that may be useful?
> - Any comments/suggestions?

MIDL?