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 4C425BBAF for ; Wed, 5 May 2010 14:12:21 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcAAHn94EuLEwExgGdsb2JhbACdQxUBAQsLCgUTBR2veAGOJwWFEw X-IronPort-AV: E=Sophos;i="4.52,333,1270418400"; d="scan'208";a="50511629" Received: from hera.mpi-sb.mpg.de ([139.19.1.49]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 05 May 2010 14:12:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Message-ID:In-Reply-To: References:Date:Subject:From:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=/d5DAjWWGEqrBisoVnock2GFQ3VqN466FC JeSlDuovw=; b=Qxmt0m5uP/BcCgKVJH7nxj49mjXlt66hvu+gLtU+1CYDVsN4gz YmGW6iiXZSlrGKavY+HpspsNrqu0rpuYuvwG1E2tbdAFlMImLnRLuTpjqu5LhjwN nWvyCfJZAB2DXHsv+wpm7fnKs/u+pbex9fV6by22v/fS8FS+YI7BED5tA= Received: from infao0525.mpi-sb.mpg.de ([139.19.1.26]:53173 helo=maniac.mpi-sb.mpg.de) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1O9dSc-0001sJ-HT; Wed, 05 May 2010 14:12:20 +0200 Received: from www-data by maniac.mpi-sb.mpg.de with local (Exim 4.69) (envelope-from ) id 1O9dSc-0001Lj-6a; Wed, 05 May 2010 14:12:18 +0200 Received: from 80.146.185.83 (SquirrelMail authenticated user rossberg) by mail.mpi-sws.org with HTTP; Wed, 5 May 2010 14:12:18 +0200 (CEST) Message-ID: In-Reply-To: <876332bsoy.fsf@frosties.localdomain> References: <602616.65342.qm@web111501.mail.gq1.yahoo.com> <4429.86797211251$1272970133@news.gmane.org> <876332bsoy.fsf@frosties.localdomain> Date: Wed, 5 May 2010 14:12:18 +0200 (CEST) Subject: Re: [Caml-list] Re: Subtyping structurally-equivalent records, or something like it? From: rossberg@mpi-sws.org To: "Goswin von Brederlow" Cc: caml-list@inria.fr User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam: no; 0.00; subtyping:01 rossberg:01 compiler:01 compiler:01 ocamlopt:01 ocaml:01 flattening:01 unboxing:01 indirection:01 degenerate:98 andreas:01 caml-list:01 constructor:01 precisely:01 int:01 "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