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 JAA12729; Mon, 10 Nov 2003 09:29:32 +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 JAA13098 for ; Mon, 10 Nov 2003 09:29:31 +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 hAA8TT125686 for ; Mon, 10 Nov 2003 09:29:29 +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 RAA12895; Mon, 10 Nov 2003 17:29:24 +0900 (JST) To: oleg_trott@columbia.edu Cc: caml-list@inria.fr Subject: Re: [Caml-list] Strange physical equality behavior In-Reply-To: <200311092125.36771.oleg_trott@columbia.edu> References: <200311091334.13734.oleg_trott@columbia.edu> <20031110103330C.garrigue@kurims.kyoto-u.ac.jp> <200311092125.36771.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: <20031110172924V.garrigue@kurims.kyoto-u.ac.jp> Date: Mon, 10 Nov 2003 17:29:24 +0900 From: Jacques Garrigue 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 runtime:01 functorial:01 clumsy:01 hashing:01 runtime:01 inlining:01 generic:01 functorial:01 incr:01 jacques:01 compiler:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Oleg Trott > So returning "true" for "sin == sin" and "sin = sin" wouldn't break > the above guarantee. Of course. And returning true for "sin = (fun x -> cos (x -. acos (-1.) /. 2))" wouldn't break it either. The specification is just designed to avoid having to do that: to allow the compiler to choose the most efficient runtime representation. It might actually just return "false" when you compare any two functions, but even this would require some more computation. > 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 The problem is that compare has several implementations, depending on the type of its argument, to be more efficient. One may imagine tricks to make sure that any one of these implementations is shared between all its occurences (but even this may be complicated while keeping inlining). But generic compare cannot be equal to float compare, while they are just separated by their types. The functorial approach offers a much cleaner solution. Alternatively, you can think of a system of registered comparison functions: type 'a comparison = {id: int; compare: 'a -> 'a -> int} let count = ref 0 let make_compare f = incr count; {id = !count; compare = f} let same f1 f2 = (f1.id = f2.id) If comparison is kept abstract, you can then safely check for equality. A lighter way would be to combine this registration with the "empty" function: two sets can be combined if they were created from the same empty set. The last solution is not to bother about that: I'm yet to see code mixing two sets of the same type but with different comparison functions. Sounds silly. 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