Email list hosting service & mailing list manager

Re: when GC is permitted Matthew Dempsky 11 Jan 2004 03:52 UTC

Michael Sperber <> writes:

> - Many (but not all) Scheme systems can quite easily support it,
>   because it already matches the FFI they have currently.
> - There's lots of experience with this kind of FFI, and it's proven
>   to work (for Scheme systems supporting it) for hooking up a wide
>   variety of C libraries.

Both of these points rest on the issue of "Scheme systems that support
it" and I have an uneasy feeling about that.  I would be more
comfortable with a C FFI SRFI that could be supported by any Scheme
system.  I believe even some more exotic implementations could provide
a Pika-like FFI, but I'll defer until I have more concrete evidence of
this before arguing it.

> - A Pika-style or JNI-style FFI could be built on top of it, and it
>   could be built in a portable manner.

That doesn't help implementations that can _only_ provide a Pika-style
or JNI-style FFI, however.  Instead code will be written to support
the present FFI and will need to be rewritten before they can be of
any use to other implementations that couldn't provide this FFI.

> So---while SRFI 50 may not be suitable for a "standard" of any kind,
> I'd say there are some arguments in favor of keeping it in place.  The
> questions are:
> - Do we clean up before moving on?  (While leaving its style intact.)
>   I think this can be done with a reasonable amount of effort.
> - What do we give the result?  My inclination is to finalize it, with
>   a clearly recognizable list of issues at the beginning.

I'm mildly confused by this last statement -- are the intentions still
to finalize SRFI-50 without resolving the issues brought up on the
mailing list or simply to move SRFI-50 to only a pseudo-standard much
akin to SYNTAX-CASE is now -- something that many implementations may
and can conveniently be used to provide SYNTAX-RULES?

It's my understanding that any existing final SRFI _could_ be
implemented by every Scheme implementation with primarily minor
changes -- most can even be implemented entirely in Scheme.  If this
is true, then SRFI-50 would set a precedence as the first SRFI that is
_not_ portable to every Scheme implementation.  I would hate for that
to happen on something as crucial as a language interface between one
of the most popular languages and one of the best.

(Of course I would have no objections to the SYNTAX-CASE-like
pseudo-standard, but you could have done that without the SRFI process
so I doubt it's up for consideration now.)