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 HAA24981; Tue, 11 Nov 2003 07:48:41 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id HAA25400 for ; Tue, 11 Nov 2003 07:48:40 +0100 (MET) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.59.238]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hAB6md122329 for ; Tue, 11 Nov 2003 07:48:39 +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 hAB6mbBU020583 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Nov 2003 01:48:37 -0500 (EST) From: Oleg Trott To: Jacques Garrigue Subject: Re: [Caml-list] Strange physical equality behavior Date: Tue, 11 Nov 2003 01:48:22 -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-Disposition: inline Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit Message-Id: <200311110148.22096.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 incr:01 non-mutable:01 functorial:01 functorial:01 selm:01 ifi:01 val:01 struct:01 pervasives:01 elt:01 3.07:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sunday 09 November 2003 08:33 pm, Jacques Garrigue wrote: > On mutable structures, [e1 == e2] is true if and only if > physical modification of [e1] also affects [e2]. By the way, either "mutable structures" or "physical modification" need to be clarified, because if (int ref list) is "mutable" then the above is wrong: let a = [ref 0];; let b = ref 0 :: a;; incr (List.hd a);; (* physical ? *) a == b;; b;; > On non-mutable structures, the behavior of [(==)] is > implementation-dependent; however, it is guaranteed that > [e1 == e2] implies [e1 = e2]. This doesn't work for "nan" though, as was recently discussed. [1] > The functorial approach offers a much cleaner solution. I'm not convinced. With non-functorial sets: type t = Leaf of string | Node of t Set.t How would you do this with functorial sets? Perhaps like this: http://groups.google.com/groups?selm=fa.dlqsupe.1c6ajga%40ifi.uio.no module A : sig type t = Leaf of string | Node of ASet.t val compare: t -> t -> int end = struct type t = Leaf of string | Node of ASet.t let compare t1 t2 = match (t1, t2) with (Leaf s1, Leaf s2) -> Pervasives.compare s1 s2 | (Leaf _, Node _) -> 1 | (Node _, Leaf _) -> -1 | (Node n1, Node n2) -> ASet.compare n1 n2 end and ASet : Set.S with type elt = A.t = Set.Make(A) (BTW, that example doesn't yet work in 3.07-2 default toplevel. And couldn't one write "let compare = Pervasives.compare" above? ) > I'm yet to see code mixing two sets of the same type but with different > comparison functions. Exactly! That's why *statically* assuring ordering function consistency is not all that important [2]. Which is why x==x would be a bigger help than recursive modules. [1] I can understand false "nan = nan", because "nan" is a kind of exception, but false "x == x" feels very non-mathematical to me. [2] I am a static typing fan, but this seems excessive. Regards, Oleg P.S. I've already participated in this discussion longer than my tolerance for language-lawyerism or passion about this issue allow me, so I'll probably end it here. -- 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