Taylan Ulrich Bayırlı/Kammer scripsit:

> I could give a better critique if I also had experience working with
> something like comparators instead of only having experience working
> without anything like them, but from looking at the spec it feels like
> it's trying too hard to abstract something where no clear and natural
> abstraction exists.  For sorting you only need a comparison procedure,
> the type-check being implicit in it.  For hash tables you only need hash
> and equivalence functions, the type check being implicit in the hash
> function.  A tree again requires a comparison.  Yes, bundling some
> together allows you to implement some generic interfaces where the
> underlying data structure might be a hash table OR a tree (or something
> else entirely, theoretically), but in the rare case you want such an
> abstract interface you can cook up something sufficient on the spot (or
> use SRFI-67 or 114 of course, but locally).  For a simple set library
> it's just fine to leak the detail that it's implemented via hash tables.

It's true that only for sets, and only in principle, do you need both
a comparison and a hash function.  But equality needs to be compatible
with comparison, and (more subtly) equality needs to be compatible with
hash (because if two objects are equal they must hash the same).
It makes sense to me, therefore, that the three functions should be
unified in a single object analogous to a Haskell type class.
(Haskell's hash tables don't use type classes, but they could.)
Adding the type test compensates for the lack of static typing
in Scheme.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
I must confess that I have very little notion of what [s. 4 of the British
Trade Marks Act, 1938] is intended to convey, and particularly the sentence
of 253 words, as I make them, which constitutes sub-section 1.  I doubt if
the entire statute book could be successfully searched for a sentence of
equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940