[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: temporarily withdrawing SRFI-50
> 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
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.