From: Nicolas C. <war...@fr...> - 2003-06-17 10:24:13
|
> > > What about: > > > > > > let s1 = ExtSet.make cmp1 in > > > let s2 = ExtSet.make cmp2 in > > > ... > > > let s = ExtSet.union s1 s2 > > > > Should raise something like "exception Comparator_differs" if not physical > > equality between s1.cmp and s2.cmp. > > Physical equality of functions can be tricky. Example: Of course, we cannot ensure the logicial equality of functions, but I'm pretty sure that most of the cases, comparators are globaly defined , because you want to have a specific comparaison behavior , different from the "Pervasives.compare" default one. > > in functor approach, you cannot actually do it since the comparator is bound > > to a type/module so errors are detected at compilation time and not at > > runtime. > > Well, I have to admit that I like the compile-time check a lot more. Then use functors :-) We will not force you to use ExtSet ! > > But that's a small tradeoff compared to the ability to define sets > > without having to define a module for every type you need. > > Defining module isn't as painful :-) It can be in fact done in single > line: > > module Iset = Set.Make(struct type t = int let compare = compare end) The problem with functors is more that your Iset is not compatible with others users (localy defined) Iset , since they're different modules. Then when you have for example two libraries using both integer sets, you have to manage the two types dinstincly and eventualy write convertion functions from one to the other, which is somehow stupid :-) Nicolas Cannasse |