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

Re: Couple things...

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 Fri, 26 Dec 2003 16:15:54 +0100, Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

"Felix" == felix  <felix@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> 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