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.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE 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 399E8BC6C for ; Thu, 7 Feb 2008 16:17:37 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADKwqkfAXQImh2dsb2JhbACQMQEBAQgKKZte X-IronPort-AV: E=Sophos;i="4.25,316,1199660400"; d="scan'208";a="22359470" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 07 Feb 2008 16:17:37 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m17FHa6e026010 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 7 Feb 2008 16:17:36 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALuvqkeCNhAB/2dsb2JhbACsUA X-IronPort-AV: E=Sophos;i="4.25,316,1199660400"; d="scan'208";a="7776471" Received: from kurims.kurims.kyoto-u.ac.jp ([130.54.16.1]) by mail1-smtp-roc.national.inria.fr with ESMTP; 07 Feb 2008 16:17:34 +0100 Received: from localhost (orion [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.13.8/8.13.8) with ESMTP id m17FHXtP026764; Fri, 8 Feb 2008 00:17:33 +0900 (JST) Date: Fri, 08 Feb 2008 00:17:29 +0900 (JST) Message-Id: <20080208.001729.233402575.garrigue@math.nagoya-u.ac.jp> To: David.Teller@univ-orleans.fr Cc: caml-list@inria.fr Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2 From: Jacques Garrigue In-Reply-To: <1202396482.6084.5.camel@Blefuscu> References: <1202396482.6084.5.camel@Blefuscu> X-Mailer: Mew version 4.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 47AB2110.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; univ-orleans:01 wiki:01 cheers:01 wiki:01 variants:01 wildcard:01 variants:01 subjective:01 polymorphic:01 caml-list:01 exceptions:01 define:02 garrigue:03 garrigue:03 seems:03 From: David Teller > As it seems that the first take on exceptionless error management has > been discarded, I have put together a second candidate. This proposal > takes into account the discussions from the first candidate, should > resolve the issues introduced by that first candidate -- and presumably > open a few other cans of worms somewhere along the way. > > The draft is available on the cocan wiki [1]. > > Cheers, > David > > [1] > http://wiki.cocan.org/osr/exceptionless_error_management/recommendation_candidate_2 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