Brian Hurt wrote:

> Jon Harrop wrote:
>
> > Actually I would say that your style is more useful than the built-in
> > Set and Map modules because you don't have to jump through hoops
> > defining your own "Int" module with its own "int" type and its own 
> > comparison function over ints every time you want a set of integers. I
> >  would put the comparison function in the set itself though.
> >
> >  
> >
> IMHO, the Int module should be in the standard library, and the Set and 
> Map modules should have already instantiated sets and maps for the 
> standard base types (int, float, string, char).

Agreed - then we could also have more sensibly located functions such as
Int.of_string (note that it's the same length as int_of_string!!) and remove
lots of random functions from Pervasives!

All that said, and especially as StdLib changes are reasonably rare, I find
having files IntSet.ml and IntSet.mli containing:

include Set.Make(struct type t = int let compare = Pervasives.compare end)

and

include Set.S with type elt = int

isn't too bad (except that you have to include IntSet.cmo/.cmx when
compiling, obviously)


David