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 9B7A9BC6C for ; Tue, 5 Feb 2008 15:12:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADj+p0fAXQImh2dsb2JhbACQKwEBAQgKKZx1 X-IronPort-AV: E=Sophos;i="4.25,308,1199660400"; d="scan'208";a="8783553" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 05 Feb 2008 15:12:51 +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 m15ECo8K021687 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 5 Feb 2008 15:12:51 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAH79p0fBMVMPk2dsb2JhbACQKwEBAQEHBAYJIJxs X-IronPort-AV: E=Sophos;i="4.25,308,1199660400"; d="scan'208";a="7630295" Received: from kabis.univ-orleans.fr (HELO ka.univ-orleans.fr) ([193.49.83.15]) by mail1-smtp-roc.national.inria.fr with ESMTP; 05 Feb 2008 15:12:50 +0100 Received: from smtps.univ-orleans.fr (localhost [127.0.0.1]) by ka.univ-orleans.fr (Postfix) with ESMTP id 4F4B712AE23; Tue, 5 Feb 2008 15:12:50 +0100 (CET) Received: from [192.168.0.12] (ras75-4-82-235-58-110.fbx.proxad.net [82.235.58.110]) by smtps.univ-orleans.fr (Postfix) with ESMTP id 415B936E5B; Tue, 5 Feb 2008 15:12:52 +0100 (CET) Subject: Re: [Caml-list] [OSR] Exceptionless error management From: David Teller To: Vincent Hanquez Cc: =?ISO-8859-1?Q?B=FCnzli?= Daniel , caml-list List In-Reply-To: <20080205101221.GA3922@snarc.org> References: <1202205644.6226.5.camel@Blefuscu> <20080205101221.GA3922@snarc.org> Content-Type: text/plain Date: Tue, 05 Feb 2008 15:12:49 +0100 Message-Id: <1202220770.6226.77.camel@Blefuscu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 47A86EE2.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; univ-orleans:01 0100,:01 0100,:01 wiki:01 monadic:01 haskell's:01 ocaml's:01 constructors:01 monads:01 variants:01 exn:01 variants:01 exn:01 pervasives:01 univ-orleans:01 On Tue, 2008-02-05 at 11:12 +0100, Vincent Hanquez wrote: > On Tue, Feb 05, 2008 at 11:00:44AM +0100, David Teller wrote: > > The debate on this subject seems to have calmed down. A tentative set > > of recommendations have been put together on the wiki [1] by some of the > > participants. It looks coherent and well-written. If nothing springs > > back to the front of the scene within a few days, I'll post this again > > to the mailing-list as a call for votes. > > looking at the page, I find a proposal (beginning), and a lots of people > disaggreeing at the end. > > I can see lots of people are concerned by using polymorphic variant (and > I certainly agree with those), and people asking for a monadic approch > (haskell's either like). I can see anything change in the proposal > regarding people's concerned, so what are you going to call for a vote ? Ok, my bad, I guess I misunderstood silence for consensus. In this case, let me try and sum up the discussion. I'll use the term "exception" for OCaml's built-in exception system. 1) This recommendation applies to functional libraries, by opposition to essentially imperative libraries such as Unix. [ I believe everybody agrees with that ] 2) This recommendation only applies to the interface of libraries, rather than their non-observable implementation or their use by clients. [ I believe everybody agrees with that ] 3) Exceptions passing library barriers should be reserved for programmer errors (i.e. invalid arguments and impossible-to-reach states) rather than previsible errors (e.g. sometimes, a key does not map to a value). We already have standard names for such exceptions. [ I have the impression nobody disagrees with that, either ] 4) At hand, to provide non-exception error management, we have the following tools: * 'a option * something such as ('a, 'b) either -- exact name and constructors remain to be decided, but the general idea is there -- which may serve, if necessary, as the base for error monads * polymorphic variants * an implementation of error monad based on exceptions, which may be trivially degraded to ('a, 'b) either whenever necessary. (I'm discounting my own suggestion for functor-based error reporting as I haven't had time to work on that, plus it would actually solve a different problem) [ Unless I'm mistaken, these are the only tools suggested so far ] 5) We may need to differentiate functions which raise exceptions. Someone on this thread suggested adding suffix "_exn" to the name of such functions. Another possibility would be to define a type such as type 'a raising = 'a to document the fact that a function may raise an exception. [ No discussion on this yet ] 6) Assuming that no other tools come into the discussion, we need to determine which tools are best for which situation. There seems to be an agreement that polymorphic variant are too fragile for general use. This leaves us essentially * ('a,'b) either (of which 'a option is just a special case) * the exception-based error monad, with the ability to produce results of type 'a or errors of type 'b . These cases are fundamentally equivalent, each may be used to build the other and result in essentially the same type signature. [ No discussion on this yet ] 7) Assuming that we use one of these two possibilities, we need to decide what to put in the 'b. Here, we may decide to: * either define module-specific types ; * or use polymorphic variants. Again, the general consensus seems to be that polymorphic variants are too risky. On the other hand, we may also decide not to specify at all what to put in 'b and to let each developer decide for their own library. [ No discussion on this yet ] As a test, I've adapted the interface of the List module. * I've included the interface for both possibilities * I've postfixing exception-raising functions with "_exn" * I've defined module-specific sum types, some of which could presumably be moved to Pervasives. You may find the result here: http://www.univ-orleans.fr/lifo/Members/David.Teller/software/exceptions/list_with_errors.mli 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.