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