On Sat, Oct 25, 2003 at 08:29:57PM -0500, xxxxxx@freenetproject.org 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