On Sat, 10 Jan 2004 19:13:26 +0100, Michael Sperber
<xxxxxx@informatik.uni-tuebingen.de> wrote:

>>>>>> "Marc" == Marc Feeley <xxxxxx@IRO.UMontreal.CA> 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.

Only if the low-level stuff is portable enough between implementations.
But to be portable enough you have to add abstractions, and in
the end you end up with high-level stuff.

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

How come? What do you mean with "in the way"? Perhaps your particular high-
level interface is insufficient?

>
> 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
> Marc> applications.
>
> In my experience, it isn't.
>

Great. With this style of discussion we are getting nowhere...

cheers,
felix