> From: Richard Kelsey <xxxxxx@s48.org>

    > The JNI style of FFI, where the C code has indirect references
    > and never the Scheme values themselves, has lots of advantages.
    > But it does add overhead.  I would prefer an FFI that allowed a
    > choice of direct or indirect values on a per-function basis.
    > Which is preferable depends a lot on what the C code is doing.
    > Such an FFI would be even larger than the current one, which is
    > already big.

Pika-style conventions come very close to letting the compiler decide
when direct vs. indirect references are needed.   So close that I
think you can just leave it at that and not suffer.

    > The interaction between Scheme threads and C code is complex.  It
    > deserves a separate SRFI because of the complexity, because of the
    > dependencies on the details of both the thread and C FFI systems,
    > and because not every FFI user is going to care about it.

If this issue were _only_ about threads, that might be a reasonable
argument.  (It also might not: one could argue that you shouldn't
finalize a SRFI which is demonstrably unsuitable for threaded
situations.)

But the problems with the current FFI include issues with
single-threaded, no-async-issue Scheme implementations including:

~ don't handle read/write barriers properly
~ don't handle transient root set members properly

By stunning coincidence (or deep physical truth, take your pick), it
turns out solving those issues _also_ make the FFI much more suitable
for systems with threads (including truly concurrent threads) and
async-execution.

There's another way entirely to look at the calling convention issues:

The draft FFI makes strong presumptions about the representations of
Scheme values and the invarients that must be maintained wrt to the
Scheme heap.  It makes these presumptions by leaving it up to the
compiler of FFI-using functions to manipulate scheme values directly,
constrained only by the semantics of C.

Pika-style conventions do not make those presumptions:  there is a
comprehensive abstraction barrier there between the Scheme value
representations, the heap invariants, and the C code.

The latter is far less restrictive on Scheme implementations.

-t