From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id CAA02960; Mon, 10 Nov 2003 02:33:39 +0100 (MET)
X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA02771 for <caml-list@pauillac.inria.fr>; Mon, 10 Nov 2003 02:33:37 +0100 (MET)
Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1])
	by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hAA1XZ100590
	for <caml-list@inria.fr>; Mon, 10 Nov 2003 02:33:36 +0100 (MET)
Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25])
	by kurims.kurims.kyoto-u.ac.jp (8.9.3p2-20030924/3.7W) with ESMTP id KAA04507;
	Mon, 10 Nov 2003 10:33:30 +0900 (JST)
To: oleg_trott@columbia.edu
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Strange physical equality behavior
In-Reply-To: <200311091334.13734.oleg_trott@columbia.edu>
References: <200311091334.13734.oleg_trott@columbia.edu>
X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20031110103330C.garrigue@kurims.kyoto-u.ac.jp>
Date: Mon, 10 Nov 2003 10:33:30 +0900
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
X-Dispatcher: imput version 20000228(IM140)
X-Loop: caml-list@inria.fr
X-Spam: no; 0.00; caml-list:01 jacques:01 oleg:01 oleg:01 3.07:01 val:01 non-mutable:01 defensive:01 mli:01 closures:01 closures:01 reflexive:01 jacques:01 bool:01 bool:01 
Sender: owner-caml-list@pauillac.inria.fr
Precedence: bulk

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