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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 90876BB81 for ; Thu, 23 Feb 2006 23:26:19 +0100 (CET) Received: from smtp6.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k1NMQJxs022621 for ; Thu, 23 Feb 2006 23:26:19 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0603.wanadoo.fr (SMTP Server) with ESMTP id 282221C00231 for ; Thu, 23 Feb 2006 23:26:19 +0100 (CET) Received: from nono (ARouen-106-1-3-31.w80-11.abo.wanadoo.fr [80.11.87.31]) by mwinf0603.wanadoo.fr (SMTP Server) with SMTP id AF3EC1C0022D; Thu, 23 Feb 2006 23:26:18 +0100 (CET) X-ME-UUID: 20060223222618717.AF3EC1C0022D@mwinf0603.wanadoo.fr Message-ID: <012001c638c8$b10139a0$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> <00e301c638c0$5368ef20$1f570b50@mshome.net> Subject: Re: [Caml-list] (int * int) <> int*int ? Date: Thu, 23 Feb 2006 23:30:03 +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 nez-perce with ID 43FE368B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; gava:01 gava:01 caml-list:01 parentheses:01 parentheses:01 int-:01 int-:01 compiler:01 indirection:01 semantically:01 constructors:01 haskell:01 unboxed:01 ocaml:01 pointer:01 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 >No. There are cases where (int*int*int) is not the same as int*int*int. >Specifically, int*(int*int*int) is different than int*int*int*int. As a sub-part of a type, ok but I speak about general parentheses... >You keep trying to assume that the parentheses are purely syntactic- >they're not. I have never say that...you can read that i have write int->int->int <> (int->int)->int >So, in terms of representation: >type t = A of int * int >is represented in memory as > tag * int * int >while >type t' = 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. >Note that in the first case it's a three word structure (two ints and a >tag), while in the second case it's a two word structure (a tag and a >reference to a tuple of two ints). But where tag could represent information both int*int and (int*int) which is the same things (modulo an indirection which could be deleted at pattern-mathching). Morever, as Jon points of, variant types do not have this curious things due to boxed values...Also when you have build a pair, semantically you want to apply the constructor on this pair...because, there no partial applications of the constructors : for a constructor A of int*int you can not write (A 3) of type int->t (as in mini-ML or Haskell). I understand (and agree) the performances reasons, but I thinks that could be deleted since the only (that i see) case where the performances are differents is in the case of pattern-matching... >No. Because in the case of B, I can snag the tuple as an independent >peice of data. For example, I can write: > let f = function B x -> fst x;; >and it works. On the other hand, if I try to write: > let g = function A x -> fst x;; >this doesn't work- because the "tuple" in A doesn't really exist as an >independent data structure (it's been unboxed). Here, Ocaml is refusing >to allow a pointer into the middle of a structure (the GC algorithm thanks >you), and doesn't want to have to allocate a tuple to hold x (this >seriously complicates pattern matching). Peraps it complicates the pattern-matching but in the second case, x could be quickly and automatically build from (A x) because tags of tuples and of concrete types are close...and you avoid this curious construction (many years that I program in ocaml and curiously, never saw this things because always build the different parameters of the concrete constructor in different "variables" ;-) so I think that it is not a problem that appear many times in ocaml programs...some one always used the two differents constructions ?) FG