From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id D39D1BC6C for ; Thu, 7 Feb 2008 17:23:41 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKu/qkfAXQInh2dsb2JhbACQMQEBAQgKKZtv X-IronPort-AV: E=Sophos;i="4.25,316,1199660400"; d="scan'208";a="8924298" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 07 Feb 2008 17:23:41 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m17GNcFK016424 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 7 Feb 2008 17:23:41 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKu/qkfBMVMQn2dsb2JhbACQMQEBAQEBBgQGCQgYm28 X-IronPort-AV: E=Sophos;i="4.25,316,1199660400"; d="scan'208";a="8924297" Received: from minbis.univ-orleans.fr (HELO min.univ-orleans.fr) ([193.49.83.16]) by mail3-smtp-sop.national.inria.fr with ESMTP; 07 Feb 2008 17:23:41 +0100 Received: from smtps.univ-orleans.fr (localhost [127.0.0.1]) by min.univ-orleans.fr (Postfix) with ESMTP id 8230112B336; Thu, 7 Feb 2008 17:23:40 +0100 (CET) Received: from [172.23.197.254] (unknown [195.221.38.254]) by smtps.univ-orleans.fr (Postfix) with ESMTP id 8B9F336E5B; Thu, 7 Feb 2008 17:23:42 +0100 (CET) Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2 From: David Teller To: Olivier Andrieu Cc: caml-list@inria.fr In-Reply-To: <95513600802070806p38d1cf6fxa5726477facb901b@mail.gmail.com> References: <1202396482.6084.5.camel@Blefuscu> <20080208.001729.233402575.garrigue@math.nagoya-u.ac.jp> <1202399557.6084.24.camel@Blefuscu> <95513600802070806p38d1cf6fxa5726477facb901b@mail.gmail.com> Content-Type: text/plain Date: Thu, 07 Feb 2008 17:23:40 +0100 Message-Id: <1202401420.6084.49.camel@Blefuscu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 47AB308A.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; univ-orleans:01 syntax:01 syntax:01 cheers:01 0100,:01 andrieu:01 univ-orleans:01 lifo:01 rectify:98 liquidations:98 wrote:01 caml-list:01 int:01 int:01 variant:02 You're correct: if I do specify manually in the interface that the type of parse_int is string -> (int, [`Syntax | `Overflow]) may_fail rather than the inferred string -> (int, [> `Syntax | `Overflow) may_fail I will be safe. I hadn't paid attention to that. I'll rectify my recommendation. I still believe that's one pitfall too many but yes, the pitfall is much smaller than what I had in mind. Cheers, David On Thu, 2008-02-07 at 17:06 +0100, Olivier Andrieu wrote: > Err no, it's not, you'll get a type error since the variant is closed > in the signature of parse_int: > > This pattern matches values of type (int, [> `IncorrectSyntax ]) > may_fail > but is here used to match values of type > (int, [ `Overflow | `Syntax ]) may_fail > The second variant type does not allow tag(s) `IncorrectSyntax > -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations.