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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 0E12A7EC6E for ; Sat, 18 Jan 2014 02:37:11 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=pra; client-ip=84.93.230.244; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=mailfrom; client-ip=84.93.230.244; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@avasout03.plus.net) identity=helo; client-ip=84.93.230.244; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="postmaster@avasout03.plus.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucCAJzZ2VJUXeb0lWdsb2JhbABZhxemPJFsgQwWDgEBAQEHDQkJEiqCJQEBAQQIAhlWDAEDAgkRBAEBAQICIwMCAhkjCgkIAgQBEgsFC4dup2+cJBeBKY1WBwaCaYFJBI8lnkA X-IPAS-Result: AucCAJzZ2VJUXeb0lWdsb2JhbABZhxemPJFsgQwWDgEBAQEHDQkJEiqCJQEBAQQIAhlWDAEDAgkRBAEBAQICIwMCAhkjCgkIAgQBEgsFC4dup2+cJBeBKY1WBwaCaYFJBI8lnkA X-IronPort-AV: E=Sophos;i="4.95,677,1384297200"; d="scan'208";a="45239539" Received: from avasout03.plus.net ([84.93.230.244]) by mail3-smtp-sop.national.inria.fr with ESMTP; 18 Jan 2014 02:37:10 +0100 Received: from XPS ([91.125.229.6]) by avasout03 with smtp id FDd81n00308vflX01Dd9p9; Sat, 18 Jan 2014 01:37:09 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=VqIaXYGn c=1 sm=1 tr=0 a=YNNwqyIk8JSiwARLj6s6Lw==:117 a=YNNwqyIk8JSiwARLj6s6Lw==:17 a=0Bzu9jTXAAAA:8 a=XCxr5DcLagoA:10 a=Xub9RBUEA-sA:10 a=Kvk-SOs2Z7YA:10 a=IkcTkHD0fZMA:10 a=r2vSxAw-AAAA:8 a=BR64nyZ84HQA:10 a=l_cqdlqD9WBv4oMhp-QA:9 a=HhR2i0Cm9kWqbkw3:21 a=T8z4Wny82GFkZGT7:21 a=QEXdDO2ut3YA:10 X-AUTH: jdh302:2500 Reply-To: From: "Jon Harrop" To: "'Simon Cruanes'" , "'Yaron Minsky'" Cc: "'Nicolas Braud-Santoni'" , References: <52D9342B.30704@gmail.com> <20140117140955.GJ11251@emmental.inria.fr> In-Reply-To: <20140117140955.GJ11251@emmental.inria.fr> Date: Sat, 18 Jan 2014 01:37:10 -0000 Organization: Flying Frog Consultancy Ltd. Message-ID: <02de01cf13ed$cf05e280$6d11a780$@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQITm23GUPanAma4/sJij0gkqtCZnwDSPG6bAiNfOa8Bucvxy5nbHJPw Content-Language: en-gb Subject: RE: [Caml-list] How much optimized is the 'a option type ? Simon Cruanes wrote: > Maybe I'm stating the obvious, but wouldn't value types be the general so= lution here? Yes but value types conflict with a uniform data representation. I think OC= aml has reached a local optimum here... Cheers, Jon. -----Original Message----- From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On Beh= alf Of Simon Cruanes Sent: 17 January 2014 14:10 To: Yaron Minsky Cc: Nicolas Braud-Santoni; caml-list@inria.fr Subject: Re: [Caml-list] How much optimized is the 'a option type ? Le Fri, 17 Jan 2014, Yaron Minsky a =C3=A9crit : > I also agree with Gabriel that an option-specific optimization is not=20 > clearly the right move. >=20 > But I wonder if a more general optimization that provided the=20 > possibility of minting "fast-path" variants. i.e., one could have an=20 > annotation that marked a given branch of a variant as the=20 > "no-indirection" one, i.e., the one that doesn't lead to the=20 > allocation of an extra block: >=20 > type ('a,'b) result =3D > | Ok of 'a [@@no_indirection] > | Error of 'b >=20 > would lead to a type where [Ok x =3D=3D x]. Some cleverness is required= =20 > then for the representation of the [Error] branch. In particular,=20 > you'd need some dynamic test you could run to see if you were using a=20 > value that was not the fast-path one. >=20 > The thing that I don't know if there's a solution for is the nesting=20 > problem. i.e., can you effectively distinguish: >=20 > Ok (Ok (Error x)) >=20 > from >=20 > Error x >=20 > since they would have the same physical representation. I'm not sure=20 > if some variant of the counting trick used for options would work here=20 > or not. But if you could get this, it would make it possible to avoid=20 > a large number of dirty Obj.magic hacks that people need to do to=20 > build efficient datastructures in practice. The fact that the stdlib=20 > needs to use Obj.magic to get the necessary performance is, I think, a=20 > sign that something important is missing from the language. I'm not=20 > sure if this is quite it, to be clear. Maybe I'm stating the obvious, but wouldn't value types be the general solu= tion here? Assuming the optimizer can guarantee that the option value will = not outlive the current scope, the value can be allocated on the stack or i= n registers. That's probably fast enough for most uses, isn't it? I think r= ust deals with option values exactly this way. -- Simon