On Sat, 03 Jan 2004 20:54:43 +0100, Michael Sperber
<xxxxxx@informatik.uni-tuebingen.de> wrote:

>>>>>> "Ray" == Ray Dillinger <xxxxxx@sonic.net> writes:
>
> Ray>     I think that you're striking a rather aggressive balance
> favoring
> Ray>     FFI functionality over portability.  While there's nothing wrong
> Ray>     with that, there's probably room for a simpler SRFI that
> specifies
> Ray>     a less general and more portable FFI.  Perhaps that SRFI should
> Ray>     come before this one.
>
> That certainly makes sense.  However, as I argued further up in this
> thread, I don't think the "less general FFI" Felix envisioned is very
> useful.
>

I do not envision a less general FFI. Please read more carefully.
I was talking about a completely different approach (not necessarily
tool-based).

Note that the Chicken FFI (for example) does not allow GC during the
invocation of foreign code, unless callbacks are explicitly used,
and that all arguments are normally passed as valid C data (i.e.
C code is provided a "view" of the data that it can understand,
similar to what I proposed). It has been useful enough to write
wrappers for OpenGL, GLUT, BLAS, SQLite, the Irrlicht 3D engine,
Sockets, most of POSIX, JAPI, MD5 stuff, Tiny CC, PCRE, SDL, GMP,
SCOP, Spread and many other things, which should be enough for
the start...

cheers,
felix