> From: xxxxxx@becket.net (Thomas Bushnell, BSG)

    > Jim Blandy <xxxxxx@redhat.com> writes:

    > > As long as SRFI's of both sorts become available within the next year,
    > > the right thing will happen.  I don't think it's necessary for SRFI-50
    > > to be withdrawn until a more opaque SRFI is written.

    > What confidence do we have that the more opaque SRFI will be written?
    > (Are there people working on drafts now?)

Indirectly and with a willingness to do it more directly.

All of what we've described as "more opaque" is part of what large
parts of Pika use internally -- because i want Pika to (ultimately) be
a collection of features not a collection of implementation
techniques.

Some of the stuff we haven't really gotten around to yet (error
handling, non-local exits, tail calls) -- those are in or on the path
of Pika too.

Pika is going faster than I thought it might.  I think the only way it
can miss being a useful R5RS Scheme this year is if I screw it up or
am unable to continue work on it.

My situation is pretty well advertised and well known to be rather
precarious but, modulo that -- yeah, sure, I think the Pika project
can float an FFI srfi this year.   And, in light of discussion
resulting from srfi-50, it'd be interesting to see if we can't
generate some volunteer work on implementing that in other systems and
also on writing some libs against it.

-t