[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pika-style from first principles

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

On Sat, 10 Jan 2004 19:13:26 +0100, Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

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

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