From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q3BAagSD014940 for ; Wed, 11 Apr 2012 12:36:42 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUBAPFdhU8machzl2dsb2JhbABCuUsqAQEBAQEGGAc7ggkBAQEEEgITGQEBNwEPCwsNLiISAQUBHAYTCBqHXgMLAwEHoCkKimSELgGFfiKBUAIEkT+VcI5WPYQL X-IronPort-AV: E=Sophos;i="4.75,404,1330902000"; d="scan'208";a="153544526" Received: from mx2.janestreet.com (HELO nyc-dmz-mxout2.janestreet.com) ([38.105.200.115]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2012 12:36:36 +0200 Received: from nyc-qsv-mail1.delacy.com ([172.25.22.57]) by nyc-dmz-mxout2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1SHuuf-0008VA-TD for caml-list@inria.fr; Wed, 11 Apr 2012 06:36:33 -0400 Received: from nyc-dmz-mxgoog1.delacy.com ([172.25.224.109] helo=mxgoog1.janestreet.com) by nyc-qsv-mail1.delacy.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1SHuuf-0002E1-Rr for caml-list@inria.fr; Wed, 11 Apr 2012 06:36:33 -0400 Received: from mail-we0-f170.google.com ([74.125.82.170]) by mxgoog1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1SHuuf-0000yP-No for caml-list@inria.fr; Wed, 11 Apr 2012 06:36:33 -0400 Received: by werh12 with SMTP id h12so538438wer.29 for ; Wed, 11 Apr 2012 03:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5XP7+0yv8DkP2HxVHlWHzf6rVNdxbzPELmehAfIt3UU=; b=vW/UKr5+OM+oBnORP1/jPx4qIv0KEQ9FggUwDq+S4EA7v1ogJ9Cpc01ezmqyGd0vZW vydRfZSUeXTnhuP4CUHLlAadBpQKTIW0aiMkJIe0HjRfV6LhSnYjYJhM0jnQz39MWxfr oXdOtpwpdAlfrdJt07vQLeimRXQaectuB8/X4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=5XP7+0yv8DkP2HxVHlWHzf6rVNdxbzPELmehAfIt3UU=; b=S/Mb0kqq/7GEHOHIWWlTyo5MhqO8hWPugEi+sJG8U6POe0By5ySENQhkN42Zg81Aug KoH5vUTRCOIGnDbZw9nDh8hElftC4yFWgrVxRpLpSwkMPBXyj1eH1he+HEJB4/n/aZv1 I7r9yOA/53EdC+8P7Fs125tysBD46y49cO5Bq1obDhlAVTkFj4fhU22nom9MjwzpOoW9 VHxUgb1Y36uxhNy85M2ZlLd24Ev/IjKHuzhtDgs+B9e4p2p2qYlHgt6sWYPSmjs/0uDZ axS2GevHeGS4Kc9rDeo8/JEZQdXOxCV6x9lVOlSHyd/M+kJs/DfRI4phEwpp5G8NPXvB iD+w== MIME-Version: 1.0 Received: by 10.216.132.6 with SMTP id n6mr8818315wei.26.1334140592879; Wed, 11 Apr 2012 03:36:32 -0700 (PDT) Received: by 10.216.235.148 with HTTP; Wed, 11 Apr 2012 03:36:32 -0700 (PDT) X-Originating-IP: [80.169.196.210] In-Reply-To: References: <874nsy1rcd.fsf@frosties.localnet> <91EB03E665BB4D7BB3CC65466956C79B@erratique.ch> <87vcl6d0oe.fsf@frosties.localnet> Date: Wed, 11 Apr 2012 11:36:32 +0100 Message-ID: From: David House To: Goswin von Brederlow Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmSOyNAAe1P29wheGIhoMHqEqow/Ki8BKTs2NN4FyPdZPla5hKPSVbJVCtLjNFnCt/6P+pN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q3BAagSD014940 Subject: Re: [Caml-list] exn vs option On Wed, Apr 11, 2012 at 11:32 AM, David House wrote: > On Wed, Apr 11, 2012 at 11:26 AM, Goswin von Brederlow > wrote: >>> However in the particular case of finding something in a data structure where the user could be confronted with a situation where he can prove that the datum will be found I think it's justified to provide both flavours. For these cases, in my own code I settled on the following pattern : >>> >>>     val find : 'a t -> key -> 'a option >>>     (** [find d k] is the value bound to [k] in [d], if any. *) >>> >>>     val get : 'a t -> key -> 'a >>>     (** [get d k] is like {!find} but raises [Invalid_argument] if [k] is not bound in [d]. *) >> >> That pattern works well if you have just one or few such functions and >> can think of nice names to differentiate them. > > A common pattern that is convenient and clear is to append _exn to the > functions that raise excetions on failure. As an example, see Core's Map module: https://bitbucket.org/yminsky/ocaml-core/src/c0e9df7b574d/base/core/lib/core_map_intf.ml We have, e.g., [find] and [find_exn].