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 75BCBBBAF for ; Wed, 5 May 2010 18:46:43 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUCAOw94UvZSMDdkWdsb2JhbACRHIwqFQEBAQEJCwoHEQMfvliFEwQ X-IronPort-AV: E=Sophos;i="4.52,335,1270418400"; d="scan'208";a="50537695" Received: from fmmailgate01.web.de ([217.72.192.221]) by mail2-smtp-roc.national.inria.fr with ESMTP; 05 May 2010 18:46:43 +0200 Received: from smtp08.web.de ( [172.20.5.216]) by fmmailgate01.web.de (Postfix) with ESMTP id A3160158BBCE0; Wed, 5 May 2010 18:46:42 +0200 (CEST) Received: from [78.43.204.177] (helo=frosties.localdomain) by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #4) id 1O9hkA-0000Bl-00; Wed, 05 May 2010 18:46:42 +0200 Received: from mrvn by frosties.localdomain with local (Exim 4.71) (envelope-from ) id 1O9hkC-0006io-V0; Wed, 05 May 2010 18:46:45 +0200 From: Goswin von Brederlow To: rossberg@mpi-sws.org Cc: "Goswin von Brederlow" , 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> <876332bsoy.fsf@frosties.localdomain> Date: Wed, 05 May 2010 18:46:44 +0200 In-Reply-To: (rossberg@mpi-sws.org's message of "Wed, 5 May 2010 14:12:18 +0200 (CEST)") Message-ID: <87ocgu9tzf.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: V01U2FsdGVkX18z5Z8eMaVVzuALNKHx5UHVg2vrnHfYTdPmEM+f OB2ILq+Mc8z9Htb0m9JH6p3I82qdm3tELC5b7r1BAv17MurE1C FRU28Vhc4= X-Spam: no; 0.00; subtyping:01 rossberg:01 compiler:01 compiler:01 ocamlopt:01 ocaml:01 flattening:01 unboxing:01 indirection:01 foo:01 foo:01 ocaml:01 degenerate:98 mfg:98 exception:01 rossberg@mpi-sws.org writes: > "Goswin von Brederlow" : >> >>>> 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. > > Yes, and I didn't say that OCaml easily could, given external constraints > like the one you mention. I only was objecting to the statement that this is > not an optimization. > >> A better representation would be to combine the two: >> >> bar { >> tag = 0 (for Bar) >> size = 2 >> field[0] = int(x) >> field[1] = int(y) >> } > > That is called flattening or unboxing, and in degenerate use cases it can > actually be costly because you have to copy the record if you extract it > first-class. However, for the original case there would be a much simpler > optimization: if a data type has only one constructor (more precisely, one > except for nullary ones), you don't need to represent its tag at all, so the > whole indirection is unnecessary. > > /Andreas Actualy in this case you don't. In foo the "tag" part of the block is unused and in bar it is the constructor id. (foo) and (Bar foo) just happen to have the same representation. Extracting a foo from a bar means you just ignore the tag part, which is already ignored anyway. The case of only having one constructor can be seen as special case for this in the case of records. But type gnarf = Gnarf of int could be represented as plain int as you say. The idea is the same. The reason ocaml does not do this is that defining lots of exception for the representation of data makes the compiler much more complicated and ocamls compiler aims at being simple. At least that's what has been said in the past. MfG Goswin