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: > Even if the SRFI were withdrawn, when I resubmit it for draft it would > still contain the following major design attributes, which are > essential to a successful collections interface. OK. > 1. Generic dispatch: This is absolutely essential in order to write > collection agnostic code. Without this ability, you cannot write > generic logic that acts on collections. This is the foundation of a > large body of library code in languages with collections. I agree. However, I would like to see the need for "collection agnostic code" justified. That sounds a lot like "generic meta-programming," but SRFI-44's support for generic meta-programming is actually very weak. (Most of the things that would support it are currently left for later SRFIs.) > 2. Necessary operators (as opposed to a Kitchen Sink): This follows > the general Scheme philosophy .... Is that really Scheme philosophy, or is it Scheme pragmatism? A recent c.l.s. explanation of the minimalism in R5RS claimed that it wasn't for philosophical reasons, but simply to avoid conflicts with existing implementations. If that's true, then this SRFI isn't following the principles, since it isn't a compromise between existing implementations. Indeed, it mostly seems to ignore prior art and set off in its own direction. If your goal really is to avoid constraining existing implementations (like R5RS did), then you really should do more research on those implementations and make a better effort to avoid incompatibilities. > 3. Metaness - This is just too important in order to have a framework > for collections interoperability. As in [1], the real power of a > collections framework comes not from the specific collections that are > eventually created .... It sounds like you're just repeating #1 here, and the same answer applies: I would like you to justify the importance of this and explain why SRFI-44 doesn't actually include the usual mechanisms to support this. There's more to it than just generic dispatch. > 4. Enumeration - A traversal mechanism is a must for collections. > Iterators/Cursors have problems as noted previously on the list. Sure, no problem there, but you may want to do more research in this area before implementing. Rather than a simplistic, one-collection, left-and-right only approach, you may want to consider the use of collection adapters, enumeration adapters, and the possibility of supporting bidirectional and random-access cursors. > For this reason arguments for withdrawal citing any of the above are > immaterial .... Problem: You've stated these as design goals without demonstrating that they are actually valuable (or even true, in the case of the "Scheme philosophy" justification). > Additionally, the SRFI process arguments are outside the scope of > discussion. We can continue to discuss this on the srfi-discuss list > if you like, but its just wasting bandwidth at this point, given that > even the editor doesn't agree that this SRFI is abusing the process in > a harmful manner. Could you please stop speaking for the editors? And writing in this "Nyah, nyah, the editors said it's OK" tone? You put a spin on it here that I didn't get from the editors' actual writings. Also, you'd do well to take things a little less personally and to treat your reviewers more fairly. For example, you've repeatedly challenged us to back up our criticisms with hard examples and detailed justifications. However, you expect us to accept your design goals as if they were obvious and universal desires. As you can see above, I feel that you're overestimating the importance of this proposal, and that some of your goals may not be supportable. -- Bradd W. Szonye http://www.szonye.com/bradd