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 0D2F87F7C2 for ; Tue, 4 Feb 2014 18:14:39 +0100 (CET) Received-SPF: Neutral (mail3-smtp-sop.national.inria.fr: domain of simon.cruanes.2007@m4x.org does not assert whether or not 129.104.30.34 is permitted sender) identity=pra; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=DIU3=XJ=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="simon.cruanes.2007@m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of SRS0=DIU3=XJ=m4x.org=simon.cruanes.2007@bounces.m4x.org designates 129.104.30.34 as permitted sender) identity=mailfrom; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=DIU3=XJ=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="SRS0=DIU3=XJ=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@mx1.polytechnique.org designates 129.104.30.34 as permitted sender) identity=helo; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=DIU3=XJ=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="postmaster@mx1.polytechnique.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMCAB0f8VKBaB4inGdsb2JhbABZg0SDWLwmFg4BAQEBAQgLCQkUKIIlAQEEASMEUgULCyEhAgIPBUmIEAgNrEahVBeRazWBFASYKoEzlB0 X-IPAS-Result: AhMCAB0f8VKBaB4inGdsb2JhbABZg0SDWLwmFg4BAQEBAQgLCQkUKIIlAQEEASMEUgULCyEhAgIPBUmIEAgNrEahVBeRazWBFASYKoEzlB0 X-IronPort-AV: E=Sophos;i="4.95,781,1384297200"; d="scan'208";a="47787906" Received: from mx1.polytechnique.org ([129.104.30.34]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 04 Feb 2014 18:14:38 +0100 Received: from emmental.inria.fr (emmental.inria.fr [128.93.0.14]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 3E64814091320; Tue, 4 Feb 2014 18:14:37 +0100 (CET) Date: Tue, 4 Feb 2014 18:14:36 +0100 From: Simon Cruanes To: Jeremy Yallop Cc: Caml List Message-ID: <20140204171435.GD11278@emmental.inria.fr> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xdAuejbAAr3yyIdQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Feb 4 18:14:37 2014 +0100 (CET)) X-Spam-Flag: No, tests=bogofilter, spamicity=0.000105, queueID=5A64614091326 X-Org-Mail: simon.cruanes.2007@polytechnique.org Subject: Re: [Caml-list] Proposal: extend try to handle success --xdAuejbAAr3yyIdQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le Tue, 04 Feb 2014, Jeremy Yallop a =C3=A9crit : > The recent thread about the representation of options highlighted a > shortcoming in the "try" construct: there isn't a convenient way to > express code that should run when the body of the "try" doesn't raise > an exception. >=20 > I'd like to propose extending OCaml with a design once suggested by > Christophe Raffalli which elegantly handles this case. The details, > along with an implementation that you can try out, are in the > following blog post: >=20 > http://ocamllabs.github.io/compiler-hacking/2014/02/04/handler-case.h= tml >=20 > Feedback welcome! This is very nice and detailed, but I'm not sure to follow how this is supposed to help in some cases you mention. Namely, the match (try Some (foo) with End_of_foo -> None) with | Some x -> a | None -> b transformation is used to preserve tail-call. Would the new try foo with | End_of_foo -> b | val x -> a present the same behavior w.r.t tail-call? If the answer is yes, then I find it very interesting :) --=20 Simon --xdAuejbAAr3yyIdQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJS8R/7AAoJEErAHQhJqmK2YDUQAJRIpO+iMAjgL2QaqWQ0MbPk 74Xc/Jvkz9bGbNnCz6p2388veCj+r53aUgaGT4VN3744NP9wyil+1QI2RE/ghYM9 MR7q48A6f9gGCUEo2BrKAAD1ESWop8VWLNxhTKvdL1Wxr9qbKRgkRKOdP6gK9Zni d5IDQY2x5BlfLK7TzjKTgWfpuWAdhEuDHOmlO9Td52kScP9iiKmqlvwBuLHtnTSz O/ogSctAT+uzl1paOT1PdQ2ewsH6/Cv6uYE0q5O7JkPcF6DCUJJl8eX8wqYvBbE9 Na4PtUIukYClX3+X2kXy3q/SLryFyXis/EesUbTP75HJ6n3uzeegh3x1dXWO4WPf 5FMRZi4IyzjhyFtYujWuOykevsvtZTBAPVP8ENXPj2VfXAXJBC1hjmvKDW47mv9P LSGZbktfMAvr8YgpY6A/+u8luIT7fBgqjxZhSUbp05jCZAiramLcZpEETTXuyhdK II3F0Ldh2IH3D1wdGekwZ+W6TEC5ZSJDg/PrBYzfPlGwnhP+68L+wfyYNbRyrd1s Bd7sH3QCINetl87AYS5cjvlvq9Y7UtBAJDX9hrxjb+VhirOZu53+Ok2LTmJDZmUo d5vO8FCH1F7LGcFS9e1ajAhHdD1LL1xLW5KZvA2kc/yJyUu987Q35XgEnnHp4ZBZ 3xCkoccly4+3vkUCKK1g =PrIL -----END PGP SIGNATURE----- --xdAuejbAAr3yyIdQ--