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 B6BA2BB81 for ; Thu, 23 Feb 2006 22:26:06 +0100 (CET) Received: from smtp6.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k1NLQ6s3032333 for ; Thu, 23 Feb 2006 22:26:06 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0604.wanadoo.fr (SMTP Server) with ESMTP id 534E71C0018B for ; Thu, 23 Feb 2006 22:26:06 +0100 (CET) Received: from nono (ARouen-106-1-3-31.w80-11.abo.wanadoo.fr [80.11.87.31]) by mwinf0604.wanadoo.fr (SMTP Server) with SMTP id E0A8A1C00183; Thu, 23 Feb 2006 22:26:05 +0100 (CET) X-ME-UUID: 20060223212605920.E0A8A1C00183@mwinf0604.wanadoo.fr Message-ID: <00e301c638c0$5368ef20$1f570b50@mshome.net> From: =?iso-8859-1?Q?Fr=E9d=E9ric_Gava?= To: "Brian Hurt" Cc: References: <006101c6389e$9bbbc440$1f570b50@mshome.net> <20060223183306.GA17390@localhost> <009b01c638ac$6a57b0e0$1f570b50@mshome.net> Subject: Re: [Caml-list] (int * int) <> int*int ? Date: Thu, 23 Feb 2006 22:30:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Miltered: at concorde with ID 43FE286E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; gava:01 gava:01 caml-list:01 indirection:01 indirection:01 constructors:01 12.:98 partial:01 pair:01 pair:01 int:01 int:01 data:02 tuple:02 tuple:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=RCVD_IN_NJABL_PROXY autolearn=disabled version=3.0.3 >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 element >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. In the concrete type case, we have two elements (and both cases pair because in both case A (2,3) works fine) and it is a problem of curryfication which is not justify. (int*int*int)=int*int*int everywhere and also (int*(int*int))=int*(int*int). But not in the concrete type case... >Also, sometimes I want one and sometimes I want the other. Sure > I can often >save copying information (and storing the duplicate information) if I can >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 of >indirection. This is why I thinks that the case (int*int) is not justify if there is no 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...). FG