[Larceny-users] FFI and Larceny libs

[Felix Klock]

On Jan 4, 2010, at 11:12 AM, Álvaro Castro-Castilla wrote:

> Is it possible to compile with Larceny some code into a library, defining a C interface for a number of functions (or just one) so I can call them from C code, dynamically loading or linking against it?

It is hypothetically possible.  After all, the entry point to the native Larceny runtime itself is invoked from a C function.

It may even be relatively easy with *Petit* Larceny, since that is designed to be hosted on top of C, and so there is no shift in the machine model when one transitions between the Larceny, and as part of its build process, it generates a library file that holds the runtime system.

But I think its fairest to say that this is not a use-case we have worked on (for either the native nor the Petit runtime), so it will be difficult to achieve, and no method for doing it is documented.  For example, to do it with native Larceny, you'd almost certainly have to link the runtime in with your own code, which means you'd have to muck with the runtime build process to mix the two together.

----

Larceny's FFI is meant to place the Larceny runtime on top of the control structure; then Larceny Scheme code invokes the functions implemented in C, shifting the machine state and marshaling values where appropriate e.g. passing along function pointers to call back into Scheme when you pass a Scheme procedure (closure) to a C routine expecting a function pointer.

So depending on what you are trying to accomplish, the easiest short-term solution may be to compile your C code into a dynamically loadable library (lets call it foo.so), then start Larceny, load up foo.so via the FFI, and then invoke an entry point to foo.so and passing along the Larceny functions that you want to access as arguments.

Does that make sense?

(The main problem with this is that not all C code is easily turned into a dynamically loadable library.  If your C code footprint is small it may be easy, but integrating Larceny into a large code base in this way is not realistic.)

-Felix