On Tue, Oct 28, 2003 at 09:05:20AM -0800, bear wrote:
> Okay, here's where our thought diverges.
>
> Some collections and dictionaries, as you point out, are going to
> have structures that imply that the implementation of these things
> is no more efficient than it can be made with the SRFI-44
> primitives.
>
> My experience though with people providing "uniform APIs" is that
> it creates a strong temptation to regard the underlying data
> structures as interchangeable modules, without regard to the
> efficiency of operations in those structures.  This becomes a
> design requirement, and then people restrict their use of primitives
> to just those primitives available in *all* of the potential modules.

<snip>
Thats hardly a design issue.  Thats more a matter of bad management or
design on the part of the end user.  The same could be said of any
Just because Scheme provides multiplication and lists
doesn't mean people routinely avoid linear algebra libraries in order to
use the more portable base operators they're built on.

> 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.

> If the SRFI-44 primitives are what's standardized, then people will
> be forced to implement these common patterns of use in the worst
> possible way in order to create "generic" code even where, on most
> dictionaries, better ways are available.
>
I doubt it.

        Scott

--