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.
scgmille@xxxxxxxxxxxxxxxxxx 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