]> On Sunday 09 November 2003 08:33 pm, Jacques Garrigue wrote: > On mutable structures, [e1 == e2] is true if and only if > physical modification of [e1] also affects [e2]. By the way, either "mutable structures" or "physical modification" need to be clarified, because if (int ref list) is "mutable" then the above is wrong: let a = [ref 0];; let b = ref 0 :: a;; incr (List.hd a);; (* physical ? *) a == b;; b;; > On non-mutable structures, the behavior of [(==)] is > implementation-dependent; however, it is guaranteed that > [e1 == e2] implies [e1 = e2]. This doesn't work for "nan" though, as was recently discussed. [1] > The functorial approach offers a much cleaner solution. I'm not convinced. With non-functorial sets: type t = Leaf of string | Node of t Set.t How would you do this with functorial sets? Perhaps like this: http://groups.google.com/groups?selm=fa.dlqsupe.1c6ajga%40ifi.uio.no module A : sig type t = Leaf of string | Node of ASet.t val compare: t -> t -> int end = struct type t = Leaf of string | Node of ASet.t let compare t1 t2 = match (t1, t2) with (Leaf s1, Leaf s2) -> Pervasives.compare s1 s2 | (Leaf _, Node _) -> 1 | (Node _, Leaf _) -> -1 | (Node n1, Node n2) -> ASet.compare n1 n2 end and ASet : Set.S with type elt = A.t = Set.Make(A) (BTW, that example doesn't yet work in 3.07-2 default toplevel. And couldn't one write "let compare = Pervasives.compare" above? ) > I'm yet to see code mixing two sets of the same type but with different > comparison functions. Exactly! That's why *statically* assuring ordering function consistency is not all that important [2]. Which is why x==x would be a bigger help than recursive modules. [1] I can understand false "nan = nan", because "nan" is a kind of exception, but false "x == x" feels very non-mathematical to me. [2] I am a static typing fan, but this seems excessive. Regards, Oleg P.S. I've already participated in this discussion longer than my tolerance for language-lawyerism or passion about this issue allow me, so I'll probably end it here. -- Oleg Trott <oleg_trott@columbia.edu> ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners