On Mon, Oct 27, 2003 at 02:54:24PM -0800, Bradd W. Szonye wrote:
>
> I've been trying to point it out, but you keep waving your hand and
> saying that you don't believe us, even when we back it up with
> interfaces and algorithmic details.

Refresh my memory, with points so I can keep track (this thread is
getting very difficult to keep up with).

> >> but what's the point in having an inefficient dictionary interface at
> >> all? There's no need for it.
>
> > The point is to describe the set of functionality need to use
> > dictionaries at all.
>
> That's not a useful goal, especially if it omits common convenience and
> performance interfaces. You'll end up standardizing only the trivial
> parts of the interface, not the "interesting" parts. Thus, you get the
> same proliferation of names.
>
> > Again this SRFI does not attempt to be the last word on APIs for any
> > of the collection types.  Take sets for example, where many operations
> > are omitted.
>
> Yeah, what's up with that? Seriously, what's the point? If every
> implementor will need to extend the interface to cover common
> operations, then you've lost the advantage of a standard interface.

You're missing the point.  Its expected that there will be future SRFIs
which define an efficient set collection, and that these SRFIs may add
additional operations, which *should* be implementable atop SRFI-44, but
will in nearly all cases be realized through more efficient, direct
implementations for specific Scheme systems.  Thats why the goal is to
define the operators needed for usability, and not all operators.

> >> Which is ridiculous, because efficiency is the whole point of having
> >> collections, and usability (including naming) is the whole point of
> >> having a standard interface. I don't know what your design goals
> >> were, but I'd be curious to hear them.
>
> > The design goals are stated pretty clearly at the beginning of the
> > SRFI. To provide a structure for agnostic use of collections and a
> > framework in which to define them, providing for the necessary set of
> > operations on them, and for interaction between them.
>
> We're trying to tell you that your theoretical "necessary set" is too
> primitive, that it doesn't reflect the *practical* necessary set of
> operations. That leads to what Bear calls "stupid programming" --
> without the performance-related interfaces, library implementors will
> only be able to rely on the naive, low-performance interfaces. Either
> that or extend the interface and lose the benefits of standardization.

I agree, but don't expect most people will be using on this SRFIs
operators.  Thats why this is a meta-SRFI of sorts after all.  On the
point of being too meta, firstly nearly all of the procedures of the
SRFI do have concrete implementations, and secondly the editors seemed
to have no problem with accepting the SRFI for draft at the start.  It
was meta at that time too, and had fewer concrete collection types.

> And there's still the problem that you haven't even implemented the
> limited set of primitives you do supply, nor shown the relationships
> with prior art. Plus the usability problems with some of the names you
> chose.

I agree that a section should be added relating the SRFI-44 primitives
to previous operators where they overlap.  After the !!/! merge, there
are few naming usability problems remaining (none that I think aren't
just incompatabilities with poorly named predecessors).

> > It is not a document to specify all possible operations on all
> > possible datastructures.
>
> It should at least specify all important operations on the data types it
> does describe.
It does.  Important operators are those that are needed to implement
others.  If it is impossible to implement an operator otherwise, then it
may justify inclusion.

	Scott