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.0 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 6EC39BC6B for ; Mon, 11 Feb 2008 09:45:13 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABear0fAXQInh2dsb2JhbACQOQEBAQgKKZYW X-IronPort-AV: E=Sophos;i="4.25,332,1199660400"; d="scan'208";a="9015909" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 11 Feb 2008 09:45:13 +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 m1B8jCMV023939 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 11 Feb 2008 09:45:12 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABear0fBMVMQh2dsb2JhbACQOQEBAQgKKZYW X-IronPort-AV: E=Sophos;i="4.25,332,1199660400"; d="scan'208";a="9015908" Received: from unknown (HELO min.univ-orleans.fr) ([193.49.83.16]) by mail3-smtp-sop.national.inria.fr with ESMTP; 11 Feb 2008 09:45:12 +0100 Received: from smtps.univ-orleans.fr (localhost [127.0.0.1]) by min.univ-orleans.fr (Postfix) with ESMTP id AD6DC12B3B5; Mon, 11 Feb 2008 09:45:09 +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 0C65B36E5B; Mon, 11 Feb 2008 09:45:10 +0100 (CET) Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2 From: David Teller To: yminsky@gmail.com Cc: OCaml In-Reply-To: <891bd3390802101816r6812a574nc074abd67faf2039@mail.gmail.com> References: <1202396482.6084.5.camel@Blefuscu> <891bd3390802101047o187a94fch8f66a6c8a457d391@mail.gmail.com> <1202681123.6278.40.camel@Blefuscu> <891bd3390802101816r6812a574nc074abd67faf2039@mail.gmail.com> Content-Type: text/plain Date: Mon, 11 Feb 2008 09:45:08 +0100 Message-Id: <1202719508.6348.42.camel@Blefuscu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 47B00B18.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; univ-orleans:01 yaron:01 minsky:01 monadic:01 indirection:01 monads:01 monads:01 unrolling:01 haskell:01 indirection:01 univ-orleans:01 lifo:01 ocaml:01 ocaml:01 trivial:01 On Sun, 2008-02-10 at 21:16 -0500, Yaron Minsky wrote: > Unless I misunderstand (which is quite likely) you can do fully > monadic error handling without this extra level of indirection. i.e.: > > let bind v f = match v with Error _ as x -> x | Ok y -> f y > let return v = Ok v > > > There you go, a fully-functioning monad. Or really a family of > monads, since you basically get a distinct monad for each type of > value in the error position. Indeed, if you replace "Error _ as x -> x" by "Error e -> Error e", you get a fully-functioning family of monads, a solution which is quite acceptable. On the other hand, that solution is rather slow, as it is essentially equivalent to checking at every step of the way whether this has been an error, then unrolling the stack manually. Unless I'm mistaken, this is the Haskell way, and it's bound to be slow (I haven't actually checked). With the extra indirection in place, we may add a little magic, as demonstrated in [1] and use actual exceptions to unroll that stack for us. [1] http://www.univ-orleans.fr/lifo/Members/David.Teller/software/exceptionless/exceptionless.ml The idea here, is that an expression of type ('a, 'b) may_fail is actually a function which may either produce a result of type 'a or raise an OCaml exception of type 'b MonadicException. Since polymorphic exceptions don't exist in OCaml, it's slightly more complicated, but the idea is there. Now, since we have actual exceptions, we need to be certain of when they are evaluated. That's why function result is there. Note that we could perform a trivial syntactic optimization using Camlp4 to avoid that call to result. Something such as attempt expr with p1 -> e1 | p2 -> e2 | ... | pn -> en being mapped to match result ( expr ) with p1 -> e1 | p2 -> e2 | ... | pn -> en > I really think we should get far enough in thinking this through to > get a workable suggestion the first time, rather than add this extra > bit of pervasive syntactic noise to allow for some possible future > change later. Good for me. > Interesting question. You are correct that "eval" might make > more sense > and I believe nobody would object to "Ok|Error" instead of > "Success| > Error". If terseness is a concern, "Bad" might even make a > shorter > replacement for "Error", although this would probably be > harder to read. > > I wouldn't mind type ('a,'b) Result = Ok of 'a | Err of 'b. Bad > seems, well, bad. I personally consider full words more readable, so I'd somewhat object to "Err". > I really think the issue is the same for imperative or functional > code. It's easy enough, even in an imperative version, to have a > function like this: > > let throw = function Ok x -> x | Error e -> failwith e > > At least assuming that the thing inside the error is a string. It > could also be an exception, which would then only need to be raised. > That's a possibility. However, I believe we mostly agree that dealing with errors as strings is usually a bad idea. Unfortunately, if the error is neither a string nor an exception, in the absence of polymorphic exceptions, your "throw" wouldn't work. Now, there's always the monadic option, but I'm not completely sure people would like monadic error-management right in the middle of their imperative code. > I do think it would be helpful to have examples of libraries using > these idioms. I concur. > For what it's worth, in a few weeks we hope to release a version of > Jane Street's standard library (which we call "core"), which has a > bunch of examples of these kinds of error-handling patterns. One > thing that's nice about our library is that it has actually been used > in anger, and so we're pretty sure that the approaches we've taken are > at least reasonably usable in practice. > > (As a side, note, I do think there is a lot of charm for using > polymorphic variants for error cases. It's quite lightweight, and > makes for very pleasant and explicit function signatures.) On that subject, one day I'm for them, one day I'm against. I believe that my biggest issue is that the default typing of polymorphic variants is open: # `blue ;; - : [ > `blue ] = `blue I believe I understand that choice. It's probably needed to be able to type fun 0 -> `blue | _ -> `red Unfortunately, as discussed previously on the mailing-list, open polymorphic variants are not quite as foolproof as regular variants. > y 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.