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 RAA07671; Tue, 29 Oct 2002 17:49:03 +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 RAA08110 for ; Tue, 29 Oct 2002 17:49:03 +0100 (MET) Received: from grace.speakeasy.org (grace.speakeasy.org [216.254.0.2]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id g9TGmmD11760 for ; Tue, 29 Oct 2002 17:49:01 +0100 (MET) Received: (qmail 1533 invoked by uid 36130); 29 Oct 2002 16:48:45 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Oct 2002 16:48:45 -0000 Date: Tue, 29 Oct 2002 08:48:45 -0800 (PST) From: brogoff@speakeasy.net To: Pierre Weis cc: "caml-list@inria.fr" Subject: Re: [Caml-list] CamlP4 Revised syntax comment In-Reply-To: <200210291130.MAA30093@pauillac.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Tue, 29 Oct 2002, Pierre Weis wrote: > To remove overloading of = (predicate and definition symbol), we could > choose to write > let pat be expression > instead of > let pat = expression > (And seemingly fro other constructs: type foo is int * int.) Right, that makes a lot of sense, even though it may be preferable to depart slightly from English grammar and just use "is" for both to save a keyword. Another place where classic OCaml could be a bit wordier is in the declaration of multiparameter data constructors; in Revised the cases of "constructor with a tupled parameter" and "constructor with several parameters" are more clearly distinguished than in OCaml, and in OCaml this is a gotcha since the implementation is different. > Let's go back to the operators per se. > > The choice for operators = and == in Caml was not random, but based on > the semantics: the == operator in C implements physical equality > (hence the need for the strcmp predicate in C); hence, we chose the > same symbol in Caml to denote physical equality. Thanks to OCaml, I've forgotten a lot of C ;-), but is this really true? The way I understood it, == is just value equality, but it doesn't work with structures on account of alignment and packing issues which would make it too costly. Since strings and arrays are nothing more than pointers in C, == on strings or arrays is just value comparison of pointers. In the latest C, which has complex numbers, I'm pretty sure equality is structural, since complex numbers get their real and complex parts checked. > You can argue that we do need a third predicate to express even deeper > semantic equality that = can check (say, for instance, equality as > graph equivalence of data), as in the comparison of co-inductive data > structures. > > To illustrate this situation let's define two ``infinite'' lists of 1s: > let rec x = 1 :: x;; > val x : int list = > [1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; > 1; 1; 1; ...] > > let rec y = 1 :: y;; > val y : int list = > [1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; > 1; 1; 1; ...] > > Now, physical equality testing correctly returns false: > > # x == y;; > - : bool = false > > But structural equality just loops for ever trying to check the > equality of those seemingly infinite lists: > > # x = y;; > Quit > > We thus may need a deeper equality to test graph equivalence! (You can > argue that = could behave like that, but this is not easy to implement > efficiently.) > > Since this new predicate is inherently costy (we need to keep track of > all already visited nodes), a longer name reminiscent of its equality > semantics could be ``===''. I hadn't thought of that, and I'm not even sure if you're just pulling my leg, but it's a good argument anyways. Is this an abstract point, or has anyone really needed a graph equivalence test over recursively defiend values in practice? -- Brian ------------------- 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