Email list hosting service & mailing list manager

Couple things... felix (22 Dec 2003 17:54 UTC)
(missing)
(missing)
(missing)
Re: Couple things... felix (24 Dec 2003 11:46 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:42 UTC)
Re: Couple things... Michael Sperber (26 Dec 2003 15:15 UTC)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
Re: Couple things... felix (04 Jan 2004 18:53 UTC)
Re: Couple things... Tom Lord (04 Jan 2004 22:39 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:17 UTC)
Re: Couple things... Tom Lord (05 Jan 2004 22:19 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:19 UTC)
Re: Couple things... felix (04 Jan 2004 18:45 UTC)
(missing)
Re: Couple things... felix (24 Dec 2003 12:03 UTC)
Re: Couple things... Jim Blandy (24 Dec 2003 16:25 UTC)
(missing)
(missing)
(missing)
Re: Strings/chars Tom Lord (24 Dec 2003 05:11 UTC)

Re: Couple things... felix 04 Jan 2004 18:45 UTC

On Sat, 03 Jan 2004 17:12:37 +0100, Michael Sperber
<xxxxxx@informatik.uni-tuebingen.de> wrote:

>>>>>> "felix" == felix  <xxxxxx@call-with-current-continuation.org> writes:
>
> felix> But the problem I see with *this* SRFI is that it specifies too
> felix> much (IMHO). If SRFI-50 is considered a (slightly) portable FFI
> felix> to C, then things could be done considerably simpler, safer and
> felix> completely portable (up to a certain point).  If SRFI-50 is
> felix> only about a semi-standard way of messing with Scheme internals
> felix> at the C level, then I'll keep my mouth shut from now on...
>
> To be honest, you've lost me in a twisty maze of natural-language
> semantics.
>

Oh, it's very easy:

If the current SRFI-50 proposal is intended as a general, portable FFI
(Foreign Function Interface), to be used among many different Scheme
implementations, then it simply fails, for reasons others have pointed out.

If the current SRFI-50 proposal is exactly meant as "Mixing Scheme with C",
that is, explicitly targeted at *not* interfacing to external libraries,
*but* intermixing C and Scheme-runtime invocations (including all the
hairy implementation-specific interelations that appear at such a level),
then this current draft proposal may be considered one possible approach
to such un undertaking.

Or put differently: you are trying to standardize a particular way of
interfacing to C, which is perhaps somewhat interesting and flexible,
but not very portable, reliable or even practical.

cheers,
felix