From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by margaux.inria.fr, Tue, 4 May 93 11:16:47 +0200 Received: from concorde.inria.fr by margaux.inria.fr, Tue, 4 May 93 11:14:43 +0200 Received: from dmi.ens.fr by concorde.inria.fr; Tue, 4 May 1993 11:15:05 +0200 Received: from arnica.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0) Date: Tue, 4 May 93 11:14:37 +0200 From: cousinea@dmi.ens.fr Message-Id: <9305040914.AA08481@arnica.ens.fr> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Xavier Leroy Subject: Re: new library modules Cc: caml-list@margaux Sender: weis@margaux The sets that you propose are not only totally ordered sets but rather totally pre-ordered and I think that it is indeed important for many applications. It is very often the case that you have to deal with a set of complex objects a part which is used for the pre-order relation. In that case, you will probably suggest to use a "map" but "maps" do not allow for multiple bindings. I have myself written a library for balanced trees and used it for several applications. I have found that, when dealing with equivalent elements, it is sometimes useful - to allow equivalent elements to occur simultaneously in the tree. - to allow the user to precise, when using function "add" , the treatment he/she wants to be performed on equivalent elements (keeping both, keeping the old one, replacing the old one by the new one) I am conscious that this goes beyond "set" operations but you get these possibilities almost for free when you have balanced trees based on a pre-order relation. Why not let us have access directly to your balanced trees package? Also: Rather than using type "int" for comparison, it would be clearer to use an explicit type comparison= Smaller | Equiv | Greater.