[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: maybe pika

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

    > From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>

    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.