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.
On Sat, 25 Oct 2003 scgmille@xxxxxxxxxxxxxxxxxx wrote: >> 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. I think he's right. This is too abstract, too meta. From joe code writer's point of view it's not clear how to use these functions. It's mathematics at it's finest, but I don't think it's a good interface. You criticized my dictionary design as being simplistic and having too many functions. Well, I designed it for the express purpose of doing simple things simply, so "simplistic" isn't an insult. As for its having "too many functions," you know how it got that way? It got that way when I used the tree and alist and hash-table libraries I had already built to construct real working projects (a parser, a dictionary, and priority queue substructures). I kept running into patterns -- things I was doing clumsily, with repeated patterns of use of the original simple functions -- and I implemented the higher-level functions to express those patterns concisely. This is for convenience of actual use according to the patterns of use that were developing in real projects. This is how libraries that are easy and convenient to use get built. I don't think your design adequately covers the real-world gaps and problems that people using this stuff are going to run into. To the extent that it covers them, it covers them at a high level of abstraction that's going to cause people headaches when they just want to do something simple or want to do it according to a pattern of use you didn't think of. Your concern for trying to provide a "uniform" API for some things that are _FUNDAMENTALLY_ of a different nature (infinite sequences and functions) has misled you; these things are different things and _should_not_ have the same API. I have been in shops where people were called upon to provide horribly inefficient functions for the purpose of fitting a uniform API. What you wind up with is lots and lots of horribly bad code that uses something in the worst possible way, simply because it can and because someone was too stupid to worry about what was efficient. Stupids writing code will fall into the habit of using a favorite data structure - say hash tables - and doing things with it using the "generic" API that it's absolutely the wrong structure for (like priority queues and ordered lists). > SRFIs needn't have unanimous approval, nor are they >gospel that must be implemented by all. If this SRFI has problems, as >you have stated without any supporting evidence, then may it die a >horrible death of neglect. 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. As you say, it's your choice. But people are giving you free advice here, and I think it's good advice. It looks to me like you are providing unnecessarily complex and abstract means for stupids to create horrible code slowly, at great expense, and doing so at the expense of R5RS semantics. I agree that this SRFI should probably be withdrawn. Bear