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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id DE92BBC6B for ; Mon, 11 Feb 2008 13:53:33 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMDTr0fAXQInh2dsb2JhbACQOQEBAQgKKZZK X-IronPort-AV: E=Sophos;i="4.25,333,1199660400"; d="scan'208";a="7900214" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 11 Feb 2008 13:53:33 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m1BCrULf002838 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 11 Feb 2008 13:53:33 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMDTr0fBMVMPfGdsb2JhbACQOQEBCQQGCCGWSg X-IronPort-AV: E=Sophos;i="4.25,333,1199660400"; d="scan'208";a="7900213" Received: from kabis.univ-orleans.fr (HELO ka.univ-orleans.fr) ([193.49.83.15]) by mail1-smtp-roc.national.inria.fr with ESMTP; 11 Feb 2008 13:53:33 +0100 Received: from smtps.univ-orleans.fr (localhost [127.0.0.1]) by ka.univ-orleans.fr (Postfix) with ESMTP id 5ECA512AF42; Mon, 11 Feb 2008 13:53:32 +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 9ACFA36E5B; Mon, 11 Feb 2008 13:53:33 +0100 (CET) Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2 From: David Teller To: yminsky@gmail.com Cc: OCaml In-Reply-To: <891bd3390802110412p4de4cba0me596640e55c6b994@mail.gmail.com> References: <1202396482.6084.5.camel@Blefuscu> <891bd3390802101047o187a94fch8f66a6c8a457d391@mail.gmail.com> <1202681123.6278.40.camel@Blefuscu> <891bd3390802101816r6812a574nc074abd67faf2039@mail.gmail.com> <1202719508.6348.42.camel@Blefuscu> <891bd3390802110412p4de4cba0me596640e55c6b994@mail.gmail.com> Content-Type: text/plain Date: Mon, 11 Feb 2008 13:53:29 +0100 Message-Id: <1202734409.6348.60.camel@Blefuscu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 47B0454A.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; univ-orleans:01 daniel's:01 monads:01 cheers:01 yaron:01 minsky:01 confuses:01 monadic:01 verbose:01 variants:01 monadic:01 monads:01 univ-orleans:01 lifo:01 wholly:98 I'm not sure where you see approach 2. My suggestion deals with approach 1, while Daniel's is approach 3. The point of monads is not related to converting exceptions, but rather to being able to compose functions without having to add a manual check at each step. And the point of this "optimized" monad implementation is just to make that faster. If the confusion is caused by my answer to your previous post, I just realized that my fixing your "bind" was a mistake. Please accept my apologies, I misread what you had written. Now, if this candidate is too confusing -- which I can't judge, as I wrote it -- perhaps something less confusing would be more appropriate. Cheers, David On Mon, 2008-02-11 at 07:12 -0500, Yaron Minsky wrote: > Something about this whole error-handling proposal confuses me. > Here's my concern: I can see 3 approaches, all having to do with what > goes in the 'b slot in the ('a,'b) status type: > 1. Use different, wholly incompatible types in 'b. This allows > you to put useful information into the signature of each > error-producing function, but basically requires individual > handling of each error. No monadic magic and no conversion to > exceptions is possible, and each error must be handled > individually. It's more explicit and more verbose. > 2. Use the same type in 'b everywhere. There's no extra > explicitness here, and I don't actually see any advantage over > just using exceptions. > 3. Use different but compatible types, e.g., polymorphic > variants. Then you get both explicitness and the chance to > use monadic or other tricks to join together the errors at the > type level. That has some clear advantages (the type system > can infer for you the ser of all possible error messages), but > we've found it leads to some sticky type error messages in > some cases. > So, I understand why someone would try (1) or (3), but (2) seems > utterly pointless to me. The proposal seems to be aiming at (1), but > then there's all this talk of monads which doesn't seem to fit (1). > > Am I missing something? > > y -- 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.