[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: temporarily withdrawing SRFI-50

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.



    > From: tb@xxxxxxxxxx (Thomas Bushnell, BSG)

    > Jim Blandy <jimb@xxxxxxxxxx> 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