On Tue, 28 Oct 2003 xxxxxx@freenetproject.org 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