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 1E9637EE99 for ; Tue, 21 Jan 2014 02:51:55 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.161; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.161 as permitted sender) identity=mailfrom; client-ip=134.160.33.161; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.161 as permitted sender) identity=helo; client-ip=134.160.33.161; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="postmaster@postman.riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYBAH3S3VKGoCGhnGdsb2JhbABZv3KBJA4BAQEBAQgLCQkUKIIlAQEBBCcRQBELGAkWDwkDAgECAUUTBgIBAYgBxA4Xjhc1OhaEIgEDiUWOXZVU X-IPAS-Result: AnYBAH3S3VKGoCGhnGdsb2JhbABZv3KBJA4BAQEBAQgLCQkUKIIlAQEBBCcRQBELGAkWDwkDAgECAUUTBgIBAYgBxA4Xjhc1OhaEIgEDiUWOXZVU X-IronPort-AV: E=Sophos;i="4.95,693,1384297200"; d="scan'208";a="45498706" Received: from postman1.riken.jp (HELO postman.riken.jp) ([134.160.33.161]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Jan 2014 02:51:52 +0100 Received: from postman.riken.jp (postman1.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id C91702588001 for ; Tue, 21 Jan 2014 10:51:49 +0900 (JST) Received: from watson.prg.gsc.riken.jp (ipm04.gsc.riken.go.jp [134.160.83.74]) by postman.riken.jp (Postfix) with ESMTPA id 2CCC732A0090 for ; Tue, 21 Jan 2014 10:51:49 +0900 (JST) Message-ID: <52DDD2B5.7060308@riken.jp> Date: Tue, 21 Jan 2014 10:51:49 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <20140119061913.72147.qmail@www1.g3.pair.com> In-Reply-To: <20140119061913.72147.qmail@www1.g3.pair.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.21.13915 Subject: Re: [Caml-list] How much optimized is the 'a option type ? On 01/19/2014 03:19 PM, oleg@okmij.org wrote: >> let rec iter_stream f s = >> match (try Some (MyStream.get s) with End_of_stream -> None) with >> | None -> () >> | Some (x, s') -> >> f x; >> iter_stream f s' >> >> where an option is used to keep the function tail-rec (I've heard >> several people tell me they often need to use this), or other cases >> like optional parameters (which are not going to move to Either), >> would be useful and future-proof. > > I concur this is a very common pattern. Almost the whole List module in batteries is written in this style, to avoid reverting lists but keeping tail-rec functions which are not when implemented naively.