Email list hosting service & mailing list manager

Couple things... felix (22 Dec 2003 17:51 UTC)
(missing)
Re: Couple things... felix (24 Dec 2003 12:01 UTC)
Re: Couple things... Jim Blandy (24 Dec 2003 16:29 UTC)
(missing)
(missing)
(missing)
Re: Strings/chars Tom Lord (24 Dec 2003 04:47 UTC)
(missing)
(missing)
(missing)
Re: Couple things... felix (24 Dec 2003 11:43 UTC)
Re: Couple things... tb@xxxxxx (24 Dec 2003 23:30 UTC)
Re: Couple things... Michael Sperber (27 Dec 2003 18:46 UTC)
Re: Couple things... felix (24 Dec 2003 12:40 UTC)
Re: Couple things... Michael Sperber (26 Dec 2003 15:16 UTC)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
Re: Couple things... felix (04 Jan 2004 18:51 UTC)
Re: Couple things... Tom Lord (04 Jan 2004 22:13 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:18 UTC)
Re: Couple things... Tom Lord (05 Jan 2004 21:53 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:19 UTC)
Re: Couple things... felix (04 Jan 2004 18:42 UTC)

Re: Couple things... Michael Sperber 26 Dec 2003 15:15 UTC

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

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla