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.7 required=5.0 tests=AWL,HTML_10_20,HTML_MESSAGE, 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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 140FBBC6B for ; Mon, 11 Feb 2008 13:12:32 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANvKr0fAXQInh2dsb2JhbACCOjeNSAEBAQgKKZJxg1E X-IronPort-AV: E=Sophos;i="4.25,333,1199660400"; d="scan'208";a="22468089" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 11 Feb 2008 13:12:31 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m1BCCMmP001163 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 11 Feb 2008 13:12:31 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAF7Kr0fRVca/kWdsb2JhbACCOjeNSAEBAQEHBAQLCBEHkneDUQ X-IronPort-AV: E=Sophos;i="4.25,333,1199660400"; d="scan'208";a="7160370" Received: from rv-out-0910.google.com ([209.85.198.191]) by mail2-smtp-roc.national.inria.fr with ESMTP; 11 Feb 2008 13:12:26 +0100 Received: by rv-out-0910.google.com with SMTP id g11so3080389rvb.57 for ; Mon, 11 Feb 2008 04:12:25 -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:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=qd129vWpOdMFYiIa4bCwCATF/PRTFPNmy0IAuAsX+IE=; b=QQ1xwhXWEiv43267hlvwDjwz8JCACLiUyu9HhoVGIZUhGIdUlNVbVE6MEkrjMwBX9f8zt9/TOerYHM2KJEhFucxLmGa1y5A8SF9qpPe0VZ7+Z+mqB+UI7D5aiWQiwo+BmxtNAuDwSQPXDchq0Ns7B2HTBCo0YCp5dm3xx9Sa3YE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=d6c84IBBdu4NztA8FXyvgeMXtV/FZt2uzLLJopTcdHlMZdPqAGa1jeXjiwE8kgPP2X1+Z7VAtcWl21LSHe6Enep8E/fVlTOvD5e/1huvTB24C15Uw6hHbwgJBoyOUUbaQcv+eYf8QA8KjFxxZlbqW1X/8uUYY5Qk3L6b3IB6/5k= Received: by 10.140.207.2 with SMTP id e2mr10524577rvg.271.1202731945580; Mon, 11 Feb 2008 04:12:25 -0800 (PST) Received: by 10.141.153.18 with HTTP; Mon, 11 Feb 2008 04:12:25 -0800 (PST) Message-ID: <891bd3390802110412p4de4cba0me596640e55c6b994@mail.gmail.com> Date: Mon, 11 Feb 2008 07:12:25 -0500 From: "Yaron Minsky" Reply-To: yminsky@gmail.com To: "David Teller" Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2 Cc: OCaml In-Reply-To: <1202719508.6348.42.camel@Blefuscu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4886_6105446.1202731945571" References: <1202396482.6084.5.camel@Blefuscu> <891bd3390802101047o187a94fch8f66a6c8a457d391@mail.gmail.com> <1202681123.6278.40.camel@Blefuscu> <891bd3390802101816r6812a574nc074abd67faf2039@mail.gmail.com> <1202719508.6348.42.camel@Blefuscu> X-Miltered: at concorde with ID 47B03BA7.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; yaron:01 minsky:01 yminsky:01 confuses:01 monadic:01 verbose:01 variants:01 monadic:01 monads:01 confuses:01 verbose:01 variants:01 monads:01 wholly:98 wholly:98 ------=_Part_4886_6105446.1202731945571 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 ------=_Part_4886_6105446.1202731945571 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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
------=_Part_4886_6105446.1202731945571--