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.
Let's consider the possibilities of a radically different approach. This is admittedly quite limited, but I think it represents a "low-hanging fruit" of useful FFI that offers a quite easy implementation to all POSIX schemes. I limit my discussion to POSIX environments here, and limit the proposal to handling scheme calls into other languages, just because POSIX provides an easy way to do that and scheme calls into C code are what I find most useful about FFI's. What if there was a program running, in a completely separate process and memory space from the scheme program, that listened for connections on a port, responded to connections with the addresses of input and output pipes, took input for a given call on the input pipe, and wrote results back on the output pipe? You could have a scheme function that starts the named program if it isn't already running, gets the input pipe and writes its args directly to that port (in some C-friendly data format), and returns an input port corresponding to the c program's output pipe, where you can read the result. This would nail portability, behave correctly with threads, get the C and Scheme calling disciplines out of each other's hair, wouldn't screw with garbage collection or continuations, and would provide an easy point of attachment for any and all C routines. Additionally, accomodating it would be a small and bounded problem for implementors, not requiring major redesign of their runtime. It would also be straightforward to use the same mechanism to implement FFI calls to fortran or FORTH or CommonLisp or whatever other languages, as long as those languages understand ports. Scheme routines implementing an external call would look something like.... ;; assumes that the program 'cport' can be found on the ;; current path and knows how to do 'foobar arg1 arg2. (define foobar (lambda (arg1 arg2) (with-input-port (FFI_write "cport" 'foobar arg1 arg2) (read)))) ;; assumes that the program 'forthport' can be found on ;; the current path and knows how to do 'foobaz arg1 arg2. (define foobaz (lambda (arg1 arg2) (with-input-port (FFI_write "forthport" 'foobaz arg1 arg2) (read)))) I'll admit freely that it wouldn't provide the flexibility of a "native" FFI, and wouldn't provide callbacks. Also, there's a design choice to be made about whether the 'port' programs can time out and just terminate themselves, or whether you want them around to hold persistent state. But it would be completely easy to use and so completely easy to understand. Anybody could (and would) use it. I'll also admit freely that if you're going to other languages for speed this is not likely to satisfy you; the synchronization and communication will introduce delays. But usually I find that I am going to other languages for operating-system calls rather than faster execution. Bear