This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
On Tue, Oct 28, 2003 at 03:42:52PM -0800, Bradd W. Szonye wrote: > scgmille@xxxxxxxxxxxxxxxxxx wrote: > > <sigh> I have not claimed the SRFI is ready for finalization, only > > that its more constructive to discuss the remaining issues and fix > > them than to withdraw, delaying a concrete collection for a year. > > 1. The SRFI process is not for preliminary ideas. If there are several > major issues to resolve, you're *supposed* to withdraw the proposal > until you've worked them out. Round and round we go. I don't characterize the remaining issues as major. > > 2. Withdrawal is not supposed to delay anything by a year. You can > potentially resubmit in 30 days and finalize 60 days after that -- IF > you resolve all of the issues that led to withdrawal in the first > place. Sorry, I was basing that off the flawed 6 month draft period. Nevertheless, it would delay concrete collections for two draft periods + 30 days, assuming the second draft didn't run into a similarly vehement opposition. I see it as a tremendous loss to withdraw an SRFI which is largely complete and of such utility to the Scheme community. > 3. The desire to get a SRFI finalized and to build on it is *not* a good > excuse to rush into finalizing an immature proposal. I agree with everything here except for the immaturity assertion which time and time I've said is your subjective opinion. > >> implementation works. > > > SRFI-34 didn't provide a complete package. > > How so? It's entirely usable on its own. It provides everything that > primitive C++ exceptions give you, for example. As is SRFI-44. The Scheme collections provided are entirely usable on their own. > > It provided the mechanism, defering to 35 for the datastructure, which > > itself defered to 36 for concrete instances of the datastructure. > > Those aren't necessary to use SRFI-34. Nor will future collections be necessary for SRFI-44 to be useful. To be sure, thats not largely the point of the SRFI, but I don't believe that conflicts with the spirit of the process, to advance portable features beyond what is in R5RS. Scott
Attachment:
pgpbSsx4d2eNq.pgp
Description: PGP signature