> From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

    Tom> I think that the (still incomplete) C API to Pika Scheme is,
    Tom> overall, a better candidate for a portable FFI.

    > It'd help if you'd be more specific as to the whys and whats.
    > From a glance at the documentation, I can only conclude "... and
    > I think not."

To be more specific:

a) It currently uses output parameters for return values and
   pointers to variables for parameters -- it addresses the GC-safety
   issues we've been discussing.

b) It adds a "scheme instance" parameter to all functions (called an
   "arena" rather than an "instance" in the Pika code).

c) It uses error return codes rather than non-local exits to signal
   errors to and from C code.

Things that aren't there in the current Pika code yet but that will be
later include polling for async interrupts, trampoline-on-the-ceiling
style tail call support, and probably the kind of
upward-continuations-from-C support I suggested.

There are some details of the Pika interfaces which are clearly not
appropriate for a portable FFI (for example, characters have
buckybits) but the interface conventions in Pika are, I think, about
right for a portable FII.

-t