Re: [Caml-list] Strange physical equality behavior

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: Oleg Trott <oleg_trott@columbia.edu>

>         Objective Caml version 3.07+2
> 
> # sin == sin;;
> - : bool = false
> # let f = sin;;
> val f : float -> float = <fun>
> # f == f;;
> - : bool = true
> 
> I don't like the fact that (sin == sin) returns false.

This is coherent with the specification of (==), which says that
it is fully specified only for mutable structures.
(** [e1 == e2] tests for physical equality of [e1] and [e2].
   On integers and characters, physical equality is identical to structural
   equality. On mutable structures, [e1 == e2] is true if and only if
   physical modification of [e1] also affects [e2].
   On non-mutable structures, the behavior of [(==)] is
   implementation-dependent; however, it is guaranteed that
   [e1 == e2] implies [e1 = e2]. *)
And note that:
  # sin = sin;;
  Exception: Invalid_argument "equal: functional value".
so returning false in this case is valid.

This is for the defensive part.

Now the real explanation: primitives (appearing as "external" in the
.mli) are not closures by themselves. A closure is built as needed.
As a result, two different occurences of "sin" will create different
closures.
If this is a problem for you, you should just be careful of wrapping
all your primitives. This is just what "let f = sin" does.
(Note however that the specification doesn't say what should be (==)
for closures either. It just happens to be reflexive in the current
implementation.)

Jacques Garrigue

-------------------
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