On Sun, 28 Dec 2003 10:25:30 +0100, Michael Sperber
<xxxxxx@informatik.uni-tuebingen.de> wrote:

>>>>>> "felix" == felix  <xxxxxx@call-with-current-continuation.org> writes:
>
> felix> Hm, you probably misunderstood: I'm not talking about making a
> SWIG-like
> felix> FFI-tool mandatory, I merely defined a language (quite similar to
> the
> felix> approach taken by SRFI-7), that specifies blocks of foreign code,
> plus
> felix> the types of the argument and result values.
>
> That's pretty much what CIG was.  (Not SWIG ...)

Ok. That was a misunderstanding on my side, then.

>
> felix> How exactly this is processed, or wether an external tool is
> felix> used, is not relevant.
>
> To be sure, what you propose may certainly be useful (even though I
> suspect it'll be less useful than you think), but *this* SRFI is
> exactly about "how this is processed" rather than what the language
> for specifying things is.  The idea is that you can then specify
> languages like the one you propose, and write portable tools for
> processing them.  One step at a time.

Agreed. But the problem I see with *this* SRFI is that it specifies
too much (IMHO). If SRFI-50 is considered a (slightly) portable FFI
to C, then things could be done considerably simpler, safer and completely
portable (up to a certain point).
If SRFI-50 is only about a semi-standard way of messing with Scheme
internals at the C level, then I'll keep my mouth shut from now on...

cheers,
felix