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