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 CAA14528; Tue, 11 Nov 2003 02:35:16 +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 CAA07084 for ; Tue, 11 Nov 2003 02:35:15 +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 hAB1ZD120140 for ; Tue, 11 Nov 2003 02:35:14 +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 KAA23627; Tue, 11 Nov 2003 10:35:07 +0900 (JST) To: malekith@pld-linux.org Cc: caml-list@inria.fr Subject: Re: [Caml-list] Strange physical equality behavior In-Reply-To: <20031110184143.GA5971@lilith.ii.uni.wroc.pl> References: <200311092125.36771.oleg_trott@columbia.edu> <20031110172924V.garrigue@kurims.kyoto-u.ac.jp> <20031110184143.GA5971@lilith.ii.uni.wroc.pl> 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: <20031111103507H.garrigue@kurims.kyoto-u.ac.jp> Date: Tue, 11 Nov 2003 10:35:07 +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 michal:01 moskal:01 malekith:01 pld-linux:01 0900,:01 jacques:01 orderings:01 overkill:01 equality:01 mutable:01 int:01 garrigue:01 garrigue:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Michal Moskal > On Mon, Nov 10, 2003 at 05:29:24PM +0900, Jacques Garrigue wrote: > > 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. > > For me it doesn't. You cannot prevent user from shooting his foot in > this case. For example consider: > > let cmp x y = Random.int () > > This is very good comparision functions, and can also be used with > functiorial interface. You may say it is silly, but random functions > (that are not total orderings) can be created by accident (for example > by comparing some mutable member or what's not). Looks like you are supporting my point. I was just saying that I'm yet to see somebody trying to take the union of two sets defined with different (supposedly correct) comparison functions. And you point out a much more probable danger, which cannot be prevented neither by the type system or dynamic checks. So using the type system (or dynamic checks) to prevent an unprobable risk, while there are much more probable ones, seems an overkill. But I won't go more in that direction: as a type freak, preventing any risk is good. 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