> From: felix <xxxxxx@call-with-current-continuation.org>

I'm a little lost in the layers of quotes here but:

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

Do I understand correctly if I restate things this way?:

There's a bunch of useful C libraries to expose to Scheme.

Generally speaking, those libraries have implicit "semantic models"
that are explainable as a narrow, tastefully selected construct built
out of C semantics.  For example, their parameters come from a fairly
simple domain of types, their flow of control is simple, and so forth.

A common use of an FFI for some high-level language is to expose such
C libraries in the high-level language.

One approach to this, that taken by the draft, is to make an FFI that
models a substantial part of the semantics of the high-level language
-- then let the FFI-using programmer fill in the gap between that and
our target libraries.

Another approach, that proposed by Felix (if I'm reading right), is to
make an FFI that captures the semantics of the libraries in a
first-class way -- then let the FFI-_implementing_ programmer fill in
the gap between that and his high-level language implementation.

As an illustration of the difference:  I _vaguely_ recall that some GL
calls take as input a sequence of vertexes.

In the draft-FFI approach, we would say "Well, scheme will hand you a
list or vector of triples or quads of Scheme numbers.  From there, you
can construct a sequence that fits the calling conventions of GL."

In the alternative approach, we would say "Here's an FFI that let's
you describe the kinds of sequence that GL calls expect (perhaps it's
an arbitrary-sized array of 3-element arrays of `float' values).   And
to you Scheme implementors:  you need to provide functions to convert
between lists or vectors and those C types."

I think it's true that the alternative can be a very effective
approach.   What I'd like to see is the model of C interfaces that
we'd like to be able to model.   The model has to include how it maps
into Scheme, too:

    <library to bind (e.g. GL)>

            ^
            |
            v
   (ffi description of GL interface)            [a]
            ^
            |
            v
   (ffi implementation for particular
     scheme implementation)
            ^
            |
            v
    <some scheme implementation>
            ^
            |
            v
    <portable use of the binding>               [b]

An alternative ffi spec would have to say how to write [a] and [b].

-t