From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 573317EE86 for ; Mon, 19 Nov 2012 19:03:35 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of edwin+ml-ocaml@etorok.net) identity=pra; client-ip=176.9.138.55; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of edwin+ml-ocaml@etorok.net designates 176.9.138.55 as permitted sender) identity=mailfrom; client-ip=176.9.138.55; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of postmaster@mail.etorok.net designates 176.9.138.55 as permitted sender) identity=helo; client-ip=176.9.138.55; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="postmaster@mail.etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN5zqlCwCYo3/2dsb2JhbAA8AwaCbMBDgQiCHgEBBAEnGQEBNgIPCxgJFg8JAwIBAgFFEwgCiAMHA6xUhDcBBY8DBow0ERWBQIMnlX+QQ4Jx X-IronPort-AV: E=Sophos;i="4.83,280,1352070000"; d="scan'208";a="182212827" Received: from mail.etorok.net ([176.9.138.55]) by mail1-smtp-roc.national.inria.fr with ESMTP; 19 Nov 2012 19:02:20 +0100 Received: from [IPv6:2a02:2f02:1022:72c6:1e6f:65ff:fe23:db0d] (unknown [IPv6:2a02:2f02:1022:72c6:1e6f:65ff:fe23:db0d]) by mail.etorok.net (Postfix) with ESMTPSA id EB93746AE for ; Mon, 19 Nov 2012 19:02:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=etorok.net; s=MAILOUT; t=1353348140; bh=DnQcenSiRVUUaJvWTHPy+wmADuorA3OcFy/ejjVdJ6E=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ns13rG1BWUG7et8pmy/fn939H3y3nMZB6Dl+SKxGpN6gmC8YiVz4uWSKZvTgLWgMF 2sZtFlndPjMW3q9Bbbym1Eq+LKuJ9UyBQhWGI7Koku7WxLoYYQzL+6ORxPLt4bepco Q/xI182bHnezSAacclhc7RlNrHZx5tXHQRjX086w= Message-ID: <50AA7427.5080104@etorok.net> Date: Mon, 19 Nov 2012 20:02:15 +0200 From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10 MIME-Version: 1.0 To: caml-list@inria.fr References: <1353347369.78785.YahooMailNeo@web111510.mail.gq1.yahoo.com> In-Reply-To: <1353347369.78785.YahooMailNeo@web111510.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.6 at mail X-Virus-Status: Clean Subject: Re: [Caml-list] The verdict on "%identity" On 11/19/2012 07:49 PM, Dario Teixeira wrote: > Hi, > > > I've found conflicting information regarding the use of "%identity", > which I hope to see clarified. > > Let's consider a typical example where a module defines an abstract > type t and provides (de)serialisation functions of_string/to_string. > Moreover, the actual implementation of t uses a string, and the > (de)serialisation functions are just identities: > > module Foo: > sig > type t > > val of_string: string -> t > val to_string: t -> string > end = > struct > type t = string > > let of_string x = x > let to_string x = x > end > > > In practice, it's not unusual for such code to be implemented using > the compiler's "%identity" builtin, all in the name of performance: > > module Foo: > sig > type t Wouldn't 'type t = private string' help the compiler optimize this? > > external of_string: string -> t = "%identity" > external to_string: t -> string = "%identity" > end = > struct > type t = string > > external of_string: string -> t = "%identity" > external to_string: t -> string = "%identity" > end > > > I realise that the use of "%identity" is dangerous. This is, after all, > how Obj.magic is defined. Moreover, it uglifies interface definitions > and makes a ridicule of the abstraction. However, on the assumption that > ocamlopt won't otherwise optimise away the no-op across module boundaries, > the use of "%identity" may well be justified for performance reasons. > > With all the above in mind, I have two questions: > > 1) Is the assumption correct that today's ocamlopt won't optimise no-ops > across module boundaries? (I know that ocamlopt does not generally engage > in MLton-style whole programme optimisation, but is this also true for > low-hanging fruit such as the first example above?) > > 2) Consider the code below. For which modules can one expect of_string calls > to be optimised across module boundaries? > > module type SIG1 = sig type t val of_string: string -> t end > module type SIG2 = sig type t external of_string: string -> t = "%identity" end > > module Impl1 = struct type t = string let of_string x = x end > module Impl2 = struct type t = string external of_string: string -> t = "%identity" end > > module A: SIG1 = Impl1 > module B: SIG1 = Impl2 > module C: SIG2 = Impl1 > module D: SIG2 = Impl2 > > Thank you in advance for your time! > Best regards, > Dario Teixeira > >