[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interface view of dictionaries

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

Attachment: pgpt2nKzMC9gc.pgp
Description: PGP signature