Re: [Chicken-users] A proposal regarding FFI

[felix winkelmann]

On Sun, 19 Dec 2004 19:36:11 -0500, Ed Watkeys <address@hidden> wrote:
> 
> Gripe number one: the inability to pass to or return from foreign
> functions anything but atoms.
> 
> I am disregarding vectors at the moment, since 1) I don't know how to
> get the length of a vector in a foreign function, 

You can use:

int C_header_size(C_word arg)

where "arg" holds a pointer to a Scheme vector (probably passed as scheme-object
to a foreign function).

> and 2) they are
> immutable 

You can use:

void C_mutate(C_word *address, C_word value)

where "address" is the (real) address of the N-th slot of the vector you want
to mutate.

> and therefore almost atom-like. Most importantly, I think
> pairs should be passable to foreign functions, and there should be
> C-accessible cons, car, and cdr functions/macros/whatevers.
> 

Consing inside C functions is currently not possible (unless you code
a primitive, which is by itself no big deal, or unless you call back into
Scheme). Car and cdr are accessible, see chicken.h, and of course
the manual. But I agree that the current documentation is incomplete
and insufficiently structured.

> Gripe number two: the general static-ness of argument passing.
> 
> Ideally, there should be some mechanism whereby a C function is passed
> an argument list structure that can then be walked (if positional) or,
> optionally, accessed by key (if keyword-based). There should also be a
> return value structure, passed into a function (by reference) that is
> used to return value(s) along with success/failure/exception
> information.
> 

Such an interface would indeed by very flexible and probably quite
safe. Yet, a static interface (like the one provided by Chicken) is
much more efficient both in time and space.

> 
> A proposed solution.
> 
>[...]

This looks quite nice. Have you read the SRFI-50 discussion archive? Your
approach might be another solution to the problem of finding a decent portable
and flexible FFI for Scheme.

> 
> The above approach mixes the C stdard variable argument approach with
> the Java servlet request/response model with a dash of Unix sysexits.h.
> Here are some advantages:
> 
> * It borrows from widely distributed memes.
> * The various functions can be implemented either as functions or
> macros.
> * It can be used to support Scheme exception throwing by using a result
> of code (e.g. SCHEME_EX_EXCEPTION) and fields in the response object.
> * It would allow a reasonably efficient implementation by not
> necessarily requiring dynamic memory allocation for the request and
> response objects.
> * It provides a way for foreign functions to tell Scheme about how to
> finalize objects passed to it, and whether Scheme can take
> responsibility for an object.
> * It support multiple return values.
> 
> Here are some things I haven't addressed:
> 
> * Creating and accessing pairs in C land. (Seems trivial.)

Well, not exactly trivial. But it provides a thick enough layer to
allow for all sorts of translations between C and Scheme data
representations.

> * Passing and returning arrays (or hashtables or...) of objects. (Not
> so trivial.)
> 
> Yes, I realize these two points are two of the big motivations for
> beginning this exercise, but given what I've written so far, dealing
> with them won't be a big deal.
> 
> Suggestions? Opinions?
> 

I think this approach is quite interesting. I find it a little heavyweight, and
I wouldn't want to write code like that - this is one reason why I don't like
the FFI-as-API approach to interfacing to foreign code, like the one
used in the SRFI-50 draft (well, that draft has numerous other problems,
but I digress...). Ok, this code could probably be machine generated.

IMHO the ideal FFI would be IDLish in nature: a declarative s-expr based
interface description that is translated to whatever a particular
Scheme implementation
needs, with support for declaring memory-management details, memory ownership,
finalization, string-representation, etc.


cheers,
felix