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 Sat, Oct 25, 2003 at 08:29:57PM -0500, scgmille@xxxxxxxxxxxxxxxxxx wrote: >> [You] really should withdraw the SRFI until (1) you resolve all of >> the major issues *and* (2) you have a complete implementation for >> every collection type to prove the concept. >> >> That second part is very important, and you can't excuse it just by >> saying that it's a "meta-SRFI." I suspect that you'll eventually run >> into problems with the way you've classified the collections. But I >> don't know for sure, and neither do you, because you don't have *any* >> implementation of a set or bag. > We're going to have to agree to disagree at this point. The API for > both bags and sets are sound, and the remaining issues with > dictionaries are all but solved .... Without a complete, concrete implementation, how do you know that? > SRFIs needn't have unanimous approval, nor are they gospel that must > be implemented by all. Correct. However, there is a requirement that they have a complete implementation. Where is the implementation of the bag and set collections? The SRFI specifies a "make-bag" procedure, but there is no such procedure in the reference implementation. I realize that your goal is not to define concrete collections. However, you must still provide a reference implementation, and that does require concrete collections to demonstrate that the interfaces are valid and implementable. > If this SRFI has problems, as you have stated without any supporting > evidence .... What do you mean, "no evidence"? > This SRFI is a necessary step towards a standard library of usable > collections, not the final word on such a library. So, barring > additional concrete criticism by others this SRFI will be finalized > sooner rather than later. Not if the editors reject it, which they should. SRFIs are *required* to "list related standards and SRFIs, including dependencies, conflicts, and replacements." SRFI-44 does not. SRFIs are required to have complete reference implementation. SRFI-44's reference implementation is incomplete; parts of it appear solely as an interface, with insufficient specification to implement that interface. Yes, it's true that it's difficult to specify a "meta-implementation" sufficiently to meet the process requirements. That's because a "meta-implementation" is not actually an implementation! The FAQ addresses this and explains that SRFIs are not appropriate for that kind of thing. > Thank you for your valid insights into the earlier flaws. The SRFI is > better because of them. Thanks. -- Bradd W. Szonye http://www.szonye.com/bradd