>
> There is no clear outline on how to build a bag or set. There's no
> implementation of those collections at all. In an SRFI, you can't just
> wave your hands and insist that the implementation is obvious. Until you
> provide an actual implementation, there's no guarantee that your design
> doc is implementable at all. Yes, you've implemented parts of it, but
> large chunks are missing, and the SRFI itself is not sufficient to
> create an implementation.

The *only* type for which a concrete implementation does not exist is
Set.  List and Vector are both sequences and thus bags.  Alist covers
dictionaries.  List is a flexible sequence.  That you believe problems
will arise when a set is implemented, despite the interface being
rigorously defined dozens of times before in other languages is really
shocking.

>
> Parts of this SRFI are implemented only in outline form, if even that.
> My opinion is that the outline is not adequate, because there's no proof
> of concept. Even if you don't want to specify a concrete bag and set in
> the SRFI itself, I insist that examples of use are necessary to
> demonstrate that the interface description is actually implementable.

Insist all you like, your arguments without supporting fact amount to an
insult to implementors, of which I am one.

>
>     Note that this is never a permanent rejection, because creation of
>     an implementation of one of the other types is a complete refutation
>     of this basis for rejection.
>
> Again, I recommend that you set aside your personal desires and
> recognize that this SRFI is incomplete.

I assure you my personal desires do not enter into this, otherwise we
would be faced with a very different SRFI already.  What I object to is
your hand-waving notion that the SRFI is incomplete without any specific
criticisms other than "I don't think its implementable."  Its quite
implementable, as Mr. Campbell will atest to, having
*portably* implemented every collection type in the SRFI with the
exception of sets.

	Scott