> I don't follow this argument.  (Actually, I can't follow a single step
> of it.)  Why does any low-level FFI automatically imply "a lot of
> Scheme implementations which will not support it," and how is this
> fact changed by having a high-level interface first?

By "low-level" I mean an FFI that exposes the details of the
implementation.  Memory management can vary so much from one
implementation of Scheme to the next that it is worthwhile to make the
FFI abstract in this regard.  An FFI where objects are converted
automatically between Scheme and C (a "high-level" FFI) can eliminate
nearly all memory management concerns (for the user of the system).

A low-level FFI may be incompatible with a particular implementation
strategy, and thus be very difficult to support (to the point that the
implementor will not invest the effort to implement it, especially if
this requires rewriting the whole memory-management system or if that
implementation of Scheme already has a decent FFI, for example:
PLT-Scheme, Chez-Scheme, Bigloo, and Gambit-C to name those I know
best).

In comparison, a high-level FFI can be supported with all internal
memory management approaches that I can think of.  So it is easier to
implement in existing Scheme systems, and there is a higher likelihood
that it will truly become a "standard" FFI.

Marc