> Another way to look at it is that *this* SRFI is exactly about writing
> those conversion functions.  (Or, to put it in Richard's words, "this
> SRFI is not that SRFI.")

OK I understand.

Frankly, I think this is wrong (i.e. proposing this FFI SRFI before a
"higher-level" FFI SRFI is proposed).  If you standardize (through the
SRFI process) low-level functionality before the high-level
functionality is worked out and standardized, you will end up with a
lot of Scheme implementations which will not support it, and a bunch of
users that use this FFI to write their code thinking that it is portable.

In my experience, a high-level FFI that only supports basic types
common to C and Scheme (numbers of various precisions, Booleans,
characters, nonnull-strings and possibly-null-strings, and
null-terminated arrays of strings) is sufficient for most applications.
A form for defining type aliases is also required so that the concrete
representation used by the C code can be abstracted (i.e. is "size_t"
a short, int, long or long long?)

Marc