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 DAA04291; Mon, 10 Nov 2003 03:25:58 +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 DAA04667 for ; Mon, 10 Nov 2003 03:25:56 +0100 (MET) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.59.238]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hAA2Pt103726 for ; Mon, 10 Nov 2003 03:25:56 +0100 (MET) Received: from tw304h3.cpmc.columbia.edu (tw304h3.cpmc.columbia.edu [156.111.84.180]) (user=ot14 mech=LOGIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hAA2PnBU023851 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 9 Nov 2003 21:25:50 -0500 (EST) From: Oleg Trott To: Jacques Garrigue Subject: Re: [Caml-list] Strange physical equality behavior Date: Sun, 9 Nov 2003 21:25:36 -0500 User-Agent: KMail/1.5.4 Cc: caml-list@inria.fr References: <200311091334.13734.oleg_trott@columbia.edu> <20031110103330C.garrigue@kurims.kyoto-u.ac.jp> In-Reply-To: <20031110103330C.garrigue@kurims.kyoto-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311092125.36771.oleg_trott@columbia.edu> X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; oleg:01 oleg:01 caml-list:01 jacques:01 3.07:01 val:01 non-mutable:01 functorial:01 clumsy:01 hashing:01 runtime:01 selm:01 ifi:01 bool:01 bool:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sunday 09 November 2003 08:33 pm, Jacques Garrigue wrote: > From: Oleg Trott > > > Objective Caml version 3.07+2 > > > > # sin == sin;; > > - : bool = false > > # let f = sin;; > > val f : float -> float = > > # 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]. *) So returning "true" for "sin == sin" and "sin = sin" wouldn't break the above guarantee. Here are my reasons for wanting such behavior (not just for "sin" of course, but also "(+)" , etc., and especially for "compare"): As was discussed lately [1], the functorial interfaces (as used in the standard library) are somewhat clumsy. One solution could be to pass the necessary ordering and hashing functions as optional parameters to "emtpy" or "create". However, in this case, functions would need to be compared at runtime compare_functions f g = try f = g with _ -> false So e.g. "compare == compare" returning true would be a lot more convenient [1] http://groups.google.com/groups?selm=fa.cvslsk1.37iiq9%40ifi.uio.no -- Oleg Trott ------------------- 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