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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 818E2BBAF for ; Wed, 5 May 2010 11:31:39 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIBAO7X4EvZSMDqkWdsb2JhbACRHIwmFQEBAQEJCwoHEQMfvgqFEwQ X-IronPort-AV: E=Sophos;i="4.52,332,1270418400"; d="scan'208";a="50497024" Received: from fmmailgate03.web.de ([217.72.192.234]) by mail2-smtp-roc.national.inria.fr with ESMTP; 05 May 2010 11:31:39 +0200 Received: from smtp05.web.de ( [172.20.4.166]) by fmmailgate03.web.de (Postfix) with ESMTP id 9C77314F5ADB2; Wed, 5 May 2010 11:31:38 +0200 (CEST) Received: from [78.43.204.177] (helo=frosties.localdomain) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #4) id 1O9ax8-00067D-00; Wed, 05 May 2010 11:31:38 +0200 Received: from mrvn by frosties.localdomain with local (Exim 4.71) (envelope-from ) id 1O9axB-0005xl-1b; Wed, 05 May 2010 11:31:41 +0200 From: Goswin von Brederlow To: rossberg@mpi-sws.org Cc: "Sylvain Le Gall" , caml-list@inria.fr Subject: Re: [Caml-list] Re: Subtyping structurally-equivalent records, or something like it? References: <602616.65342.qm@web111501.mail.gq1.yahoo.com> <4429.86797211251$1272970133@news.gmane.org> Date: Wed, 05 May 2010 11:31:41 +0200 In-Reply-To: (rossberg@mpi-sws.org's message of "Tue, 4 May 2010 14:47:02 +0200 (CEST)") Message-ID: <876332bsoy.fsf@frosties.localdomain> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX19x4sEEO3gWLE/xhtdT4PODjPo7p1aVEo/Rs4jz 2Ah3mbgG4MivFPdHXB42XnaUQ2PgpILpTS3pYuPSaHvZ1ixq2s XiLdg0kRs= X-Spam: no; 0.00; subtyping:01 rossberg:01 le-gall:01 compiler:01 compiler:01 ocamlopt:01 foo:01 foo:01 baz:01 baz:01 ocaml:01 arrays:01 blubber:98 mfg:98 caml-list:01 rossberg@mpi-sws.org writes: > "Sylvain Le Gall" : >> >> This is not about optimized compiler in this case but about data >> representation. Even if you use an optimized compiler (which is not >> really the case with ocamlopt), you won't change datastructure >> representation to optimize. > > What do you mean? There is no reason in general why a compiler cannot > optimize data representations, and some do in cases like this. How could it? At least for any type that is public in a module. The data representation is part of the ABI. As such it is fixed and can in no way be optimized by the compiler. Only thing you can do is change the ABI and define a more optimized representation in the first place. As example type foo = { x : int; y : int; } type bar = Bar of foo Currently a bar is represented as foo { tag = 0 size = 2 field[0] = int(x) field[1] = int(y) } bar { tag = 0 (for Bar) size = 1 field[0] = &foo } 2 Blocks taking up 5 words. A better representation would be to combine the two: bar { tag = 0 (for Bar) size = 2 field[0] = int(x) field[1] = int(y) } A single block of 3 words. This also works for type bar = Foo of foo | Blub of foo | Blubber of foo but not for type baz = Baz of bar There are lots of cases where the representation could be improved for special cases. But ocaml I think only does that for float arrays or records that only contain floats. But that is a design decision and not something the compiler can just optimize. MfG Goswin