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