[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 Sun, 28 Dec 2003 10:25:30 +0100, Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

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