xxxxxx@freenetproject.org wrote:
> The *only* type for which a concrete implementation does not exist is
> Set.  List and Vector are both sequences and thus bags.

You have not implemented any bags that are not also sequences. How do
you know whether the bag interface, on its own, is complete and
implementable? In one of my recent replies, I pointed out a problem of
this nature. Had you tried to implement a bag, you might have noticed
that sooner.

Also, I find that it's difficult to justify a "bag" type that is
distinct from the base "collection" type -- all of the collections
described so far can support the bag interface.

Could you justify the hierarchy you chose for the collection types? Are
they based on classification? If so, do they obey the Liskov
Substitution principle? Are they prototype-based objects?
Interface-based generics? Do you have the implementation experience to
back up your answer?

"I've seen it done in other languages" is not a sufficient answer.
That's a hand-wave, not an implementation. What works in other languages
may not port well to Scheme. The SRFI's prologue mumbles a bit about
polymorphism, but doesn't explain what model of polymorphism it relies
on. Have you defined the interface in a way that's too closely tied to
Tiny CLOS? Have you implemented it in a more portable, less
environment-dependent way?

Parts of the SRFI has a vendor-specific reference implementation, and
some parts have no implementation at all, just a vague outline of how
people should go about it.

>> 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.

Again you accuse me of providing no support or evidence! And I'm not
insulting anybody here. If you give implementors nothing more than a
vague outline, they'll all implement things in different ways, which is
the death of a standard interface.

Sure, I've waved my hands a bit too. But I've also given you concrete
examples like the fibonacci sequence, the silent change of semantics for
vector-set!, and much other evidence which shows that:

1. The implementation is not mature.

2. The document does not meet the requirements for the SRFI Process.
   Specifically, it does not discuss the relationship with standards and
   other SRFIs -- not even for blatant incompatibilities.

Do you really want more supporting facts? How about the facts that the
SRFI is three months overdue, has undergone major changes (some of them
recent), still has major issues to resolve, and still lacks a complete
implementation.

That sure sounds like the SRFI is "immature" and "incomplete" to me, as
defined by the SRFI process doc. That's not intended to be an insult to
you personally, but it seems that you're taking it that way. I've tried
hard to be a good reviewer, talking to the document and not to you, but
you seem determined to take my comments as personal insults.

Let it go. If you want to be insulted, to ignore me, and to push through
this SRFI whether it's complete or not, feel free. I'll go on record as
saying that it's not complete and that it should be rejected according
to the documented SRFI process.

>> 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 ....

Then why do you sound like you've been personally insulted, and that
you're eager to push your baby through the SRFI process whether it's
mature or not?

> 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."

What I *actually* said is that you have not yet demonstrated that it is
implementable. Your reference implementation is not complete. I suspect
that there *will* be problems using it for anything more than trivial
collection types, but you can't tell me otherwise because you haven't
actually implemented the whole thing.

In other words, it's not mature enough to finalize it.

> Its quite implementable, as Mr. Campbell will atest to, having
> *portably* implemented every collection type in the SRFI with the
> exception of sets.

That alone is enough to show that the implementation is not complete!
And sets aren't the only ommission; you haven't demonstrated that bags
are feasible as distinct types, either. Nor have you demonstrated that
the class hierarchy makes sense as written (or even explained which kind
of polymorphism it relies on).
--
Bradd W. Szonye
http://www.szonye.com/bradd