Accueil     À propos     Téléchargement     Ressources     Contactez-nous

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

[Caml-list] Strange physical equality behavior
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
 Date: 2003-11-11 (06:48) From: Oleg Trott Subject: Re: [Caml-list] Strange physical equality behavior
```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:

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