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 Tue, 28 Oct 2003 scgmille@xxxxxxxxxxxxxxxxxx wrote: >> These allow the programmer to say what s/he means, and the code will >> realize the benefits of efficiency where it's available. It won't >> have to be written stupid unable to take advantage of available >> efficiencies, it won't have to be rewritten stupid when someone >> changes to a different dictionary structure that doesn't support >> the exact same set of operations efficiently, and it won't then >> stay stupid when they switch back. > >So? This in no way argues against future standardization of those >efficient operators *for collections on which they can be defined*. >Quite the opposite. I *hope* to see future SRFIs that do just that. You know, there's almost no point in talking to you. You're missing the point a lot. It argues for the implementation of those operations *EVEN ON DICTIONARIES WHERE THEY'RE NOT PARTICULARLY EFFICIENT*. That was, in fact, my whole point. Only if the operations exist on all dictionaries will they be used in "generic" code. Only if they are used in "generic" code will the benefits, where available, be realized in general systems. I'd start with examples, but if I did, then you'd dismissivley handwave about the examples rather than responding to my point. But, honestly, I think that I've said this often enough, and in enough ways, that anybody who remotely cared about it would have understood it by now. So I'm done. You have a SRFI that will die a long lingering death of neglect, and, where implemented, cause patterns of use that are profoundly stupid to become the norm. Fine. Your problem. I've told you about it and you're not listening. From now on I'm bowing out of this discussion. Bear