Markus Mottl [mailto:markus@mail4.ai.univie.ac.at] wrote:
> On Wed, 11 Jul 2001, Krishnaswami, Neel wrote:
> > For instance, I recently wrote yet another set 
> > implementation, because the functorial interface to the Set module 
> > in the standard library wouldn't let me use it in a fully polymorphic
> > fashion.
> 
> This is a shortcoming of the standard library that there are no
> polymorphic implementations of "Set" and similar. It's very easy to
> extract a polymorphic (module-) version from the existing code. 

Are there any plans to add them? I /really/ need them, and while
their lack has led to me learning an awful lot about red-black
trees, Patricia tries and treaps, I can't help but feel that I've
been busy reinventing the wheel. :)

If desired, I can offer a red-black tree implementation that 
implements the whole Map and Set interfaces. (I wonder how many 
other people have been inspired by that Okasaki paper?) 

> Note that the non-polymorphic version also has advantages for 
> users: e.g. they don't have to pass around comparison functions 
> all the time.

??? I don't understand this. In both the object version I posted 
and the functorial version that Brian Rogoff posted, a hacker
only needs to mention the comparison function when creating the
type, and then never again when making or using trees.

In fact, my first experiment along these lines was to use a record 
with a tree and a comparison function in it. But even there, one 
could use currying to mention the function comparison only once. 
(I rejected it because it permitted trees with different but type-
compatible comparison functions to intermix.)

--
Neel Krishnaswami
neelk@cswcasa.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr