On Fri, 26 Dec 2003 16:15:54 +0100, Michael Sperber
<xxxxxx@informatik.uni-tuebingen.de> wrote:

>>>>>> "Felix" == felix  <xxxxxx@call-with-current-continuation.org> writes:
>
> Felix> My idea is simpler, more safe, more portable and does away with
> most GC
> Felix> and character-representation issues (as far as I'm able to
> understand
> Felix> Unicode-related problems): define blocks of code externally, with
> a
> Felix> properly defined set of arguments/results and their types. The
> foreign
> Felix> bindings could be defined in a "binding"-language, perhaps even by
> taking
> Felix> ideas from SRFI-7:
>
> While this approach is very seductive, my personal experience
> (stemming from writing or supervising the writing of) many, many lines
> of C bindings and investing considerable thought and work into this
> kind of thing, is that it's neither simple to implement, nor general
> enough to address even a significant portion of the C binding needs
> out there in the real world.
>
> For a comparatively small example: scsh had something like this once
> (called CIG), which we largely did away with it for the 0.6 series
> precisely because it tended to make things harder rather than easier.
>
> Moreover, this kind of approach still doesn't absolve you from
> specifying what the C-level interface with Scheme looks like.  See,
> say, SWIG for an example where "the simple approach" was used in the
> beginning, and then more and more half-baked stuff was stapled and
> Scotch-taped on later.
>
> This kind of thing could still be very useful, mind you, but it
> doesn't meet with the stated goals of this particular SRFI.
>

Hm, you probably misunderstood: I'm not talking about making a SWIG-like
FFI-tool mandatory, I merely defined a language (quite similar to the
approach taken by SRFI-7), that specifies blocks of foreign code, plus
the types of the argument and result values. How exactly this is processed,
or wether an external tool is used, is not relevant.

The problem I see with the current SRFI-50 draft is that it will lead
to extremely subtle and hard to find bugs, because too much implementation
specific knowledge is implicitly expected from someone using the FFI.

cheers,
felix