> > Dictionaries have conceptual issues precisely because they are a
> > mapping where all other collection styles in the SRFI are just
> > collections.
>
> Agreed. I keep waffling between two different concepts for the
> dictionary: is it a collection of mappings, or is it a bag with an
> index?

A dictionary is a datastructure which stores values that can be accessed
using a key.  Anything more specific than that assumes a specific
implementation type.  It may be implemented as a bag with an index, but
its important to keep the types distinct, otherwise you risk shoehorning
many dictionary types into an awkward interface in order to look like a
bag with an index.  You can't necessarily assume a collection of
mappings either (although to some extent you must to implement the
folding enumerator).

>
> I'm a bit surprised that vector wasn't defined as pure-mutable.
Yes, it should be.

> > This is more an issue for programmers than the specification of the
> > SRFI.
>
> I can't disagree more strongly. If the specification makes errors likely
> and reviews difficult, that's a problem with the spec, not the
> programmers. This is such an important issue that language standards
> committees include it in their charters! (See C++.)
>
> I didn't analyze the procedures closely the first time around -- I found
> a few issues before I ever got that far -- but when I did I noticed
> several inconsistencies and error-prone naming conventions. Examples:
>
>     vector-set! incompatible with R5RS

>     mutable vs immutable (seem like opposites, but they're not)
This is really a problem with haphazardly calling purely mutable
functions just mutable at times.  This has been fixed.

>     string= vs string=? (names too similar, different semantics)
The problem is that *? in Scheme most often indicates a unary or binary
predicate.  The equality function of this SRFI (and of SRFI
1) behaves differently enough that I could argue that calling it *=?
would actually misrepresent its meaning more.

>     *-all vs *-any (names similar and counterintuitive)

The names are quite intuitive if you read them right:

(*-remove-all collection bag) => remove all of bag from collection
(*-remove-any collection bag) => remove any occurence of bag from
collection

> Perhaps not. But I do see a few major issues:
>
> 1. Quiet incompatibility with R5RS.
I agree.
> 2. Error-prone naming conventions.
Maybe.  I'm not convinced that the same argument can't be made from the
other side of the fence, i.e. that the names of procedures from other
libraries are themselves ill conceived.

> 3. Problems with the dictionary interface.
I agree on some levels.  The dictionary equivalence problem is very
real.  I don't think however that the general contract of the dictionary
API is all that broken.  It deliberately seeks to describe dictionaries,
not map them onto any other model.

	Scott