[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pika-style from first principles
>>>>> "Marc" == Marc Feeley <feeley@xxxxxxxxxxxxxxxx> writes:
Marc> Frankly, I think this is wrong (i.e. proposing this FFI SRFI before a
Marc> "higher-level" FFI SRFI is proposed). If you standardize (through the
Marc> SRFI process) low-level functionality before the high-level
Marc> functionality is worked out and standardized, you will end up with a
Marc> lot of Scheme implementations which will not support it, and a bunch of
Marc> users that use this FFI to write their code thinking that it is portable.
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?
I'd say the low-level stuff is exactly the place to start, because it
can be used to explain the semantics of any high-level mechanism.
Moreover, there are lots of ways of interfacing C code where a
high-level interface would only be in the way---specifically, when
generating the glue code from header files, SWIG-like descriptions, or
some other set of pre-existing bindings.
Marc> In my experience, a high-level FFI that only supports basic types
Marc> common to C and Scheme (numbers of various precisions, Booleans,
Marc> characters, nonnull-strings and possibly-null-strings, and
Marc> null-terminated arrays of strings) is sufficient for most
In my experience, it isn't.
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla