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=1.4 required=5.0 tests=SPF_NEUTRAL 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 0CA8ABC6C for ; Thu, 31 Jan 2008 21:05:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIS4oUfAXQImh2dsb2JhbACQIgEBAQgKKZd6h3E X-IronPort-AV: E=Sophos;i="4.25,286,1199660400"; d="scan'208";a="8587290" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 31 Jan 2008 21:05:14 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0VK5DXA016797 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 31 Jan 2008 21:05:14 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAEO4oUdIDtbkX2dsb2JhbACQGBUEBAsFFAWYEYdx X-IronPort-AV: E=Sophos;i="4.25,286,1199660400"; d="scan'208";a="22030980" Received: from hu-out-0506.google.com ([72.14.214.228]) by mail4-smtp-sop.national.inria.fr with ESMTP; 31 Jan 2008 21:05:13 +0100 Received: by hu-out-0506.google.com with SMTP id 16so544968hue.7 for ; Thu, 31 Jan 2008 12:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=kcJ8BRdm3C8Ydj8WdjV4J6PZ42vexXf5KDR/i1TSlEY=; b=xJxI2utYeDR9VMBxIoXQ+QW4suuLKSJ+nW8KwWYAot9LbIKvcKeJBniKntmmhUoXXKG/FK6uWmzHZM6lSE0Hw3GaIQg2uJ11RMKryIHAr1lY1eGrhvwhdMg+/E2b44gn6P8XmtldvTK63AN6uPFFtLrJoLV5lxrXczabV3Y3eME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K4OFAXan0HFr6VboVqvomtIFW/gllzpn/jlHY+vfCzdXS9INk8mfvZYcqcRSWTLXVDhnVQAhS9hgjrmMzPlaINAOQntZz2JgsrIGpeGk34vOshX6L0cRylZcWgx1+T/fDepmphYkkVSTDDtLM7KbvVGiiEYQT9ICMPgchg5IkaI= Received: by 10.142.194.1 with SMTP id r1mr1528626wff.123.1201809911010; Thu, 31 Jan 2008 12:05:11 -0800 (PST) Received: by 10.142.139.13 with HTTP; Thu, 31 Jan 2008 12:05:10 -0800 (PST) Message-ID: <527cf6bc0801311205n522c1c2ajfd46ea0fa773292@mail.gmail.com> Date: Thu, 31 Jan 2008 21:05:10 +0100 From: "blue storm" To: "David Teller" Subject: Re: [Caml-list] [OSR] Exceptionless error management Cc: "Michael Ekstrand" , caml-list@inria.fr In-Reply-To: <1201807692.6565.14.camel@Blefuscu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9d3ec8300801310157r77b86fc0k80f40b1df36091c2@mail.gmail.com> <0640C30E-07B5-4885-AC38-671755BB79AA@erratique.ch> <47A1D68B.70700@fmf.uni-lj.si> <87myqmcc7v.fsf@jehiel.elehack.net> <1201807692.6565.14.camel@Blefuscu> X-Miltered: at discorde with ID 47A229F9.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; runtime:01 ocamlexc:01 ocamlexc:01 variants:01 monads:01 libs:01 variants:01 univ-orleans:01 exn:01 functorize:01 overkill:01 sig:01 cheers:01 exn:01 univ-orleans:01 My two cents : - It's easy to derive variant-defined functions from the exception-using ones, with virtually no performance cost. Going the other way is not as practical, and i assume it has a higher runtime overhead - We will need to document our functions in any case : the exception name generally doesn't provide an accurate enough description of the causes of the error (be it an exception, a polymorphic variant, ...) - The added safety is good, but not (in my eyes) essential for every use; we could use tools, eg. OcamlExc ( http://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm ) to check the safety as well - In most situation, exceptions allow for a more natural and more concise code than options/variants/monads, precisely because they can break flow of control (eg. in a "for" loop), and because our libs are not quite adapted to that kind of programming now (where is mapM ?) I would favor the conservative solution : still provide the exception handling by default, and allowing an additional option/variants version. On 1/31/08, David Teller wrote: > Differentiating functions sounds like a good idea. > > We may either: > * add a suffix after function names whenever they may raise exceptions > (suffix "_exn" sounds good to me) > * add a suffix after function names whenever they are variants that > don't raise exceptions (say, suffix "_maybe") > * write two different (sub)modules with the same set of functions, one > module being named Exception, the other one being named Option. > > What else ? We could presumably functorize modules upon the definition > of a error-delivery mechanism, but that might be overkill. > > Say > module type ErrorMechanism = sig > type 't; (**The type of a failure.*) > type 'a can_fail; > (**The type of a value that can either succeed > and produce a result of type 'a or fail and > produce an error of type t. *) > value fail : t -> 'a can_fail ; > (**Fail. Depending on the mechanism, this may > either return some variant on option or > throw an exception.*) > > value succeed : 'a -> 'a can_fail ; > (**Succeed.*) > end;; > > We could also introduce an exception monad which would be an > intermediate choice between using exceptions and using option types and > such. I have a just written a prototype for this, I'll try and release > it soon. > > Cheers, > David > > On Thu, 2008-01-31 at 08:16 -0600, Michael Ekstrand wrote: > > While `get' and `search' are probably OK (I presume that `get' raises > > an exception, and `search' returns an option type), we must be > > careful. If multiple functions is the standard, I would prefer that a > > naming/variant system be recommended (such as get and get_exn). If we > > come up with clever names for our various functions, I fear the Java > > Queue API syndrome (where you can get a value with any of 4 different > > functions, and add with another 4, that mostly differ in how they > > handle error and thread blocking conditions and the names have little > > correlation to the differences). > > > > - Michael > > -- > 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. > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >