[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.

I left out (d), that it has a read/write barrier over local variables
containing Scheme values.