From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id ABC9DBB81 for ; Thu, 23 Feb 2006 22:57:23 +0100 (CET) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k1NLvMHB002911 for ; Thu, 23 Feb 2006 22:57:23 +0100 Received: from [192.168.42.2] (bhurt.dsl.visi.com [208.42.141.66]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 3FE93826A; Thu, 23 Feb 2006 15:57:22 -0600 (CST) Date: Thu, 23 Feb 2006 15:57:23 -0600 (CST) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: =?iso-8859-1?Q?Fr=E9d=E9ric_Gava?= Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] (int * int) <> int*int ? In-Reply-To: <00e301c638c0$5368ef20$1f570b50@mshome.net> Message-ID: References: <006101c6389e$9bbbc440$1f570b50@mshome.net> <20060223183306.GA17390@localhost> <009b01c638ac$6a57b0e0$1f570b50@mshome.net> <00e301c638c0$5368ef20$1f570b50@mshome.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-94784562-1140731843=:9569" X-Miltered: at concorde with ID 43FE2FC3.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 gava:01 indirection:01 compiler:01 parentheses:01 indirection:01 constructors:01 unboxed:01 ocaml:01 pointer:01 complicates:01 work-:98 wrote:01 partial:01 ints:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-94784562-1140731843=:9569 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 23 Feb 2006, Fr=E9d=E9ric Gava wrote: >> This isn't correct- the same problem shows up in the difference between: >> int*int*int and int*(int*int)- i.e. the difference between (1,2,3) and >> (1,(2,3)). In the first case (in both examples) I have a three element >> tuple, in the second case I have a two element tuple whose second elemen= t >> is also a two element tuple (and thus I have the layer of indirection). > > Hum, no...here we have three (int) or two (one int and one pair) elements= =2E > In the concrete type case, we have two elements (and both cases pair beca= use > in both case A (2,3) works fine) and it is a problem of curryfication whi= ch > is not justify. (int*int*int)=3Dint*int*int everywhere and also No. There are cases where (int*int*int) is not the same as int*int*int.=20 Specifically, int*(int*int*int) is different than int*int*int*int. So, in terms of representation: type t =3D A of int * int is represented in memory as tag * int * int while type t' =3D B of (int * int) is represented in memory as tag * (int * int) where in both cases tag is the tagging information added by the compiler.= =20 Note that in the first case it's a three word structure (two ints and a=20 tag), while in the second case it's a two word structure (a tag and a=20 reference to a tuple of two ints). You keep trying to assume that the parentheses are purely syntactic- they're not. >> I can often >> save copying information (and storing the duplicate information) if I ca= n >> add the level of indirection- this is important if I'm copying the >> information a lot. On the other hand, if the information isn't being >> duplicated a lot, then I can save memory by not having the extra level o= f >> indirection. > > This is why I thinks that the case (int*int) is not justify if there is n= o > partial application of the concrete constructors (because the level of > indirection could be avoid at the time of pattern-matching : you quickly > modify the data of the concrete type to have a tuple...). No. Because in the case of B, I can snag the tuple as an independent=20 peice of data. For example, I can write: =09let f =3D function B x -> fst x;; and it works. On the other hand, if I try to write: =09let g =3D function A x -> fst x;; this doesn't work- because the "tuple" in A doesn't really exist as an=20 independent data structure (it's been unboxed). Here, Ocaml is refusing=20 to allow a pointer into the middle of a structure (the GC algorithm thanks= =20 you), and doesn't want to have to allocate a tuple to hold x (this=20 seriously complicates pattern matching). Brian --8323328-94784562-1140731843=:9569--