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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id ACA687F708 for ; Fri, 17 Jan 2014 15:02:20 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@tot-dmz-mxout1.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@tot-dmz-mxout1.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoABAJFf2FImacjlnGdsb2JhbABZhBm7EYEHHg4BAQEBAQYWCTyCJQEBAQRAAQE3AQ8LCw0uIQESAQUBHAYTG4dVAxEDAp0WixOEUgEFklgNhVYRBoxrgWEzB4Q4iUuKdIF6gWyMXINOGCmEdw X-IPAS-Result: AoABAJFf2FImacjlnGdsb2JhbABZhBm7EYEHHg4BAQEBAQYWCTyCJQEBAQRAAQE3AQ8LCw0uIQESAQUBHAYTG4dVAxEDAp0WixOEUgEFklgNhVYRBoxrgWEzB4Q4iUuKdIF6gWyMXINOGCmEdw X-IronPort-AV: E=Sophos;i="4.95,670,1384297200"; d="scan'208";a="53718505" Received: from mx5.janestreet.com (HELO tot-dmz-mxout1.janestreet.com) ([38.105.200.229]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jan 2014 15:02:19 +0100 Received: from tot-oib-smtp1.delacy.com ([172.27.22.15] helo=tot-smtp) by tot-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1W4A01-0007DN-V0 for caml-list@inria.fr; Fri, 17 Jan 2014 09:02:17 -0500 Received: from tot-dmz-mxgoog1.delacy.com ([172.27.224.14] helo=mxgoog2.janestreet.com) by tot-smtp with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W4A01-0007x9-Tw for caml-list@inria.fr; Fri, 17 Jan 2014 09:02:17 -0500 Received: from mail-la0-f42.google.com ([209.85.215.42]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1W4A01-0003dQ-MI for caml-list@inria.fr; Fri, 17 Jan 2014 09:02:17 -0500 Received: by mail-la0-f42.google.com with SMTP id hr13so1619388lab.15 for ; Fri, 17 Jan 2014 06:02:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ejMTx7Sjtu2EZ5YX0q56BqPrk5iuDPbcpwOXEkDArSE=; b=1bfVxW0l4Huu3i8JM10KAUviHdx4atcyy73BOUCKqdPQwPRGdbGOz70HNp/GMyIZyn aFzr1zwejcYBvyaEKvk/rrKsFZdAUhs263nqbo8qcvj3WvmLS9vTTbOd0KieJFD6rY69 0jChOqgJZxOIjlG5E94PGE4C9EqngXJ5cdICA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ejMTx7Sjtu2EZ5YX0q56BqPrk5iuDPbcpwOXEkDArSE=; b=inS/XV/8XN0cHeMiG6ORpvH9Cd++ZV2FWQvSG2LN1b/U9xbCpISLA2p62o52KiES4y 5zB+PdZeZkVMM1dH2LI6fiEkMoyI4p6G++s+yXIDJGSQgqas5xijgOW0UIul0fLdEOsU u2+yQK4/LmkAdsHAIbHnfBBAKtZU1Cldbbrz/oiQSf7PiXKEKtF2Fqq/L0p58HYfRZ/D PA5x/TqM8XCNzOShOW+9gb7NxghrU1hPSUq+LqGCoYeB6JAEz/pQk30KKpgMe7OV/wRa iwX62PDiaRt8SQ1myIFMtCUEsreXPpdWWT9Q/Xdg810tqKg60HeVTOHFsM3HIyXnfLJA t64w== X-Gm-Message-State: ALoCoQl3H6nmeBMZ+fFDyWZIDYfibI7RO0Dh5b7x9E7Tf+pI7Kjf8GgJqcYjDCSZXXAQKMQ43GlqYix4UrNt0N27CoH2XeZbpsOyRaSq9IWwWttAxBdm5Xu8nBuNZJLWdT4Abczyg691b8Cz6Ks53N/dL0A9G4YW3w== X-Received: by 10.112.171.41 with SMTP id ar9mr261246lbc.74.1389967337029; Fri, 17 Jan 2014 06:02:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.171.41 with SMTP id ar9mr261243lbc.74.1389967336961; Fri, 17 Jan 2014 06:02:16 -0800 (PST) Received: by 10.112.5.70 with HTTP; Fri, 17 Jan 2014 06:02:16 -0800 (PST) In-Reply-To: <52D9342B.30704@gmail.com> References: <52D9342B.30704@gmail.com> Date: Fri, 17 Jan 2014 09:02:16 -0500 Message-ID: From: Yaron Minsky To: Nicolas Braud-Santoni Cc: "caml-list@inria.fr" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] How much optimized is the 'a option type ? I also agree with Gabriel that an option-specific optimization is not clearly the right move. But I wonder if a more general optimization that provided the possibility of minting "fast-path" variants. i.e., one could have an annotation that marked a given branch of a variant as the "no-indirection" one, i.e., the one that doesn't lead to the allocation of an extra block: type ('a,'b) result =3D | Ok of 'a [@@no_indirection] | Error of 'b would lead to a type where [Ok x =3D=3D x]. Some cleverness is required then for the representation of the [Error] branch. In particular, you'd need some dynamic test you could run to see if you were using a value that was not the fast-path one. The thing that I don't know if there's a solution for is the nesting problem. i.e., can you effectively distinguish: Ok (Ok (Error x)) from Error x since they would have the same physical representation. I'm not sure if some variant of the counting trick used for options would work here or not. But if you could get this, it would make it possible to avoid a large number of dirty Obj.magic hacks that people need to do to build efficient datastructures in practice. The fact that the stdlib needs to use Obj.magic to get the necessary performance is, I think, a sign that something important is missing from the language. I'm not sure if this is quite it, to be clear. y On Fri, Jan 17, 2014 at 8:46 AM, Nicolas Braud-Santoni wrote: > On 17/01/2014 12:23, Jonathan Kimmitt wrote: >> In my humble opinion the main purpose of Some _ | None is to avoid the >> requirement for a nil pointer in OCaml. If an external function wants to >> return nil in order to indicate, for example that a certain resource is = not >> available, it can return None instead and this prevents dereferencing a = nil >> pointer in OCaml because the None cannot be dereferenced. > Yes. > This doesn't forbid the compiler from representing 'a option values as > pointers. > Indeed, the type system already enforces that the None case is handled > and the representation of None and Some _ do not matter. > > That said, I agree with Gabriel Scherer : adding optimizations specific > to 'a option might refrain people wanting to switch to more appropriate > datatypes. > However, would is be possible to =93optimize away=94 all types of the form > =93type 'a t =3D X of 'a | A | B | ...=94 (with at most one non-constant > constructor) ? > Would it be worth doing ? > > > Kind regards, > Nicolas >