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.
> Bradd W. Szonye wrote: >> Whoah, NOT agreed. This is that "academics, not engineering" attitude >> again, except that efficiency concerns are important even to >> academics. This is important stuff, and I'd appreciate it if you >> stopped sweeping things like efficiency and usability under the rug. >> Leaving it for later is OK, but pretending that they're just >> "implementation details" is not. scgmille@xxxxxxxxxxxxxxxxxx wrote: > I'm not saying efficiency is unimportant, but the job of a > specification is to describe semantics, but to do so in a way that > doesn't preclude efficient implementation. In the world of data structures and algorithms, efficiency issues are basic requirements, just as important as the semantics. You can leave them until later -- you don't need to specify them as extensively as the C++ standard library does. But it's something that you need to at least *consider* when writing up a design spec for collections. It need not go into the document, but you need to know that it's actually implementable in a usable way. I seriously believe that you need to withdraw the SRFI. The major issues suggest that the implementation is not mature enough. In fact, there *is no reference implementation at all* of most of the spec. You excused this by calling it a meta-SRFI, and I accepted that for a while. But now I realize that you really do need to implement the whole thing, and that's what my "experience issues" message was about. What you call a "meta-implementation" is what most engineers call a "design document." You haven't shown that the design is mature or even that it's implementable on a wide variety of Schemes. Personally, I'm not sure that this "meta-implementation" is appropriate for an SRFI at all, since it really is just a design. If you had a good set of concrete collections implemented to the design, I wouldn't make a big deal of it, but right now we have no way of knowing whether the design is usable by library authors or users. I strongly suggest that you read the SRFI Process Document and FAQ again. Your SRFI is already overdue, it's had several major changes, it still has major issues with the dictionary concept, and most of it is unimplemented. Based on that, you really should withdraw the SRFI until (1) you resolve all of the major issues *and* (2) you have a complete implementation for every collection type to prove the concept. 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. -- Bradd W. Szonye http://www.szonye.com/bradd