> From: xxxxxx@freenetproject.org

    > > >  For something like a hash table, sure -- at creation time I really
    > > >  need to establish what notion of equality (and hence, hashing) is in
    > > >  play -- but for bags?

    > > OK.  This point I concede.  I don't like the handling of equality
    > > functions either.  I'd probably prefer optional comparison arguments
    > > to many of the procedures, but I'd have to talk with Scott and
    > > Matthias about this before becoming certain that that would be better.

    > I can see both sides here, but let me state the other side that
    > you may not be considering.  There may be bags whose internal
    > representation is dependent on the equivalence function in the
    > same way that its important for hash table based dictionaries.
    > A bucket based bag, for example, may need the equivalence
    > function to classify the values it stores, allowing it to have
    > logarithmic performance for contains? because it has pre-sorted
    > its values in a certain way.  This is the rationale for
    > pre-specification of the equivalence function.  If all bags were
    > completely unorganized collections of values and all had
    > guaranteed O(N) lookup times, then it would be just fine to pass
    > the equivalence function at call time.

Perhaps in all cases, the optional equivalence predicate to a
constructor is mostly just a hint.

If I make a hash table using EQV? but then modify it with:

	(dictionary-set! d k v)		; set using equal?

instead of

	(dictionary-setv! d k v)	; set using eqv?

then perhaps the results are simply undefined.   The non-generic
interface to (normal) association lists works that way, for example.
I've certainly used hash-table libraries that work that way.

Haven't had too many problems with it and, since the result is
"undefined", a hash table would certainly be permitted to signal an
error.

-t