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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 0D672BC6D for ; Thu, 7 Feb 2008 16:52:38 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGe4qkfAXQImh2dsb2JhbACQMQEBAQgKKYEVmkg X-IronPort-AV: E=Sophos;i="4.25,316,1199660400"; d="scan'208";a="22361272" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 07 Feb 2008 16:52:38 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m17FqY93027681 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 7 Feb 2008 16:52:38 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPC3qkfBMVMQn2dsb2JhbACQMQEBAQEBBgQGCQgYgRWaRg X-IronPort-AV: E=Sophos;i="4.25,316,1199660400"; d="scan'208";a="7059039" Received: from minbis.univ-orleans.fr (HELO min.univ-orleans.fr) ([193.49.83.16]) by mail2-smtp-roc.national.inria.fr with ESMTP; 07 Feb 2008 16:52:37 +0100 Received: from smtps.univ-orleans.fr (localhost [127.0.0.1]) by min.univ-orleans.fr (Postfix) with ESMTP id DA36612B336; Thu, 7 Feb 2008 16:52:37 +0100 (CET) Received: from [172.23.197.254] (unknown [195.221.38.254]) by smtps.univ-orleans.fr (Postfix) with ESMTP id 1579136E5B; Thu, 7 Feb 2008 16:52:40 +0100 (CET) Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2 From: David Teller To: Jacques Garrigue Cc: caml-list@inria.fr In-Reply-To: <20080208.001729.233402575.garrigue@math.nagoya-u.ac.jp> References: <1202396482.6084.5.camel@Blefuscu> <20080208.001729.233402575.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain Date: Thu, 07 Feb 2008 16:52:37 +0100 Message-Id: <1202399557.6084.24.camel@Blefuscu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 47AB2942.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; univ-orleans:01 variants:01 wildcard:01 variants:01 subjective:01 wildcards:01 val:01 syntax:01 re-raise:01 subjective:01 cheers:01 univ-orleans:01 lifo:01 liquidations:98 polymorphic:01 On Fri, 2008-02-08 at 00:17 +0900, Jacques Garrigue wrote: > I have little to say about the approach itself (it may certainly be > good to know that there are no hidden exceptions.) > > However, the comments at the end look just like copied from Vincent > Hanquez's mail. > For me, points 2 and 3 make no sense at all. > Polymorphic variants allow to check exhaustiveness... as long as you > use exhaustive pattern matching (i.e. no wildcard, exactly like for > normal variants.) > And they _cannot_ pollute any namespace, since they define nothing. > The other points are subjective. > > Jacques Garrigue Indeed, they are mostly copied from that mail. You are correct, the remark about pollution was hasty, I've just removed it. As for allowing to check exhaustiveness, I grant you that I should have formulated this differently, but the truth remains that in presence of wildcards, polymorphic variants allows the very same kind of errors I'm trying to prevent in this candidate. For instance, let's consider the following extract: val parse_int : string -> (int, [`Syntax | `Overflow]) may_fail match result (parse_int "523.5") with | Success i -> (*...*) | Error `IncorrectSyntax -> (*...*) | _ as e -> throw e This code is perfectly legitimate. It just happens that it's also false, because we have used the wrong exception name. It's also the kind of code which I expect will be quite common: deal with one kind of error and ignore (or re-raise) the others. So, while polymorphic variants are quite powerful and quite useful, I also believe they're the wrong tool for the task. As for points 1 and 4 are subjective, well, they're open for debate. Cheers, David -- 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.