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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 6BBD4BC6B for ; Sun, 10 Feb 2008 19:47:18 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHfVrkfAXQImh2dsb2JhbACCOjeNSgEBAQgKKZFcg00 X-IronPort-AV: E=Sophos;i="4.25,330,1199660400"; d="scan'208";a="7875032" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 10 Feb 2008 19:47:18 +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 m1AIlHNF015632 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sun, 10 Feb 2008 19:47:18 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOvVrkfRVca6mWdsb2JhbACCOjeNSgEBAQEBBgQECwgYkWCDTQ X-IronPort-AV: E=Sophos;i="4.25,330,1199660400"; d="scan'208";a="22447917" Received: from rv-out-0910.google.com ([209.85.198.186]) by mail4-smtp-sop.national.inria.fr with ESMTP; 10 Feb 2008 19:47:16 +0100 Received: by rv-out-0910.google.com with SMTP id g11so2876661rvb.57 for ; Sun, 10 Feb 2008 10:47:05 -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=I0OGkvecsm01N8y4bo5JRatoiDsWNgpEgKwp8Xo8DGs=; b=uEb1E1qzZixzCUJSWEUQrl6jAcKS9UfDDOruewlk9C1ZU6NVcUB4fpBFbWqdfq+j/lrf8JyuR0mwMzTjymEFIoCX6k58hKTkJ8bMwqNRKjaSw3mtpTQdP56pstTatRPxw0n3a8j0xg+2OuurDLCqoK1toeHhlxqPZooenJj411U= 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=r/ZoxaRUh4jQbN0cAFi+EvELXmzI+fGceyA4wCMianJa38kuI5R/5jj9p8k8Ca8yUnYqCW81KDg7kMYckGZYqxRIHzVfewORProsFiYh4FnbbpRBF892sF3/83rK3Hrgfm3UGbz/PbRLqnG3cGAUBkeasIFfDR+I9VByDAo25Ig= Received: by 10.141.50.17 with SMTP id c17mr10117166rvk.33.1202669225820; Sun, 10 Feb 2008 10:47:05 -0800 (PST) Received: by 10.141.153.18 with HTTP; Sun, 10 Feb 2008 10:47:05 -0800 (PST) Message-ID: <891bd3390802101047o187a94fch8f66a6c8a457d391@mail.gmail.com> Date: Sun, 10 Feb 2008 13:47:05 -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: <1202396482.6084.5.camel@Blefuscu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3233_25419886.1202669225766" References: <1202396482.6084.5.camel@Blefuscu> X-Miltered: at discorde with ID 47AF46B5.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; yaron:01 minsky:01 yminsky:01 nomenclature:01 pipelines:01 nomenclature:01 pipelines:01 exception:01 exception:01 caml-list:01 functions:01 functions:01 exceptions:01 exceptions:01 imperative:01 ------=_Part_3233_25419886.1202669225766 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline A couple of quick thoughts about the proposal: - I don't understand the motivation behind separating out may_fail and status. In the case where no explicit error is returned, we're happy to return an ordinary option. Why not return a status when we want to return an error condition? And I don't understand the argument about wanting to delay evaluation until the function result is called. Why is that good, and if it's good, why do we still support functions that return options? The whole thing seems to add verbosity with little gain. - I think some attention on nomenclature is in order. In the libraries Jane Street uses, we have something similar to status (called "result"), but the type is "Ok of 'a | Error of 'b" rather than "Success of 'a | Error of 'b", simply for terseness. Also, having a function called "result" which converts a "may_fail" into a "status" seems like one name too many. I would call both the function and the type the same thing (either status or result). Unless, of course, you want to imply something material about the operation, in which case calling it "eval" or somesuch would make sense. - I don't understand why this proposal is only for functional data types. I didn't find the motivation given in the OSR for this convincing. I feel like the use of exceptions involves roughly the same tradeoffs when you're using imperative and functional code. If you have long functional pipelines, doing exception handling at each stage is a pain, much as it is if you do long sequences of imperative operations. That's why I think the goal should not be for the interfaces to be "exceptionless" so much as to make it easier to keep track of where exceptions might and might not be thrown, so that the reader of a piece of code knows where to stop and worry about exceptions. y ------=_Part_3233_25419886.1202669225766 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline A couple of quick thoughts about the proposal:
  • I don't understand the motivation behind separating out may_fail and status.  In the case where no explicit error is returned, we're happy to return an ordinary option.  Why not return a status when we want to return an error condition? And I don't understand the argument about wanting to delay evaluation until the function result is called.  Why is that good, and if it's good, why do we still support functions that return options?  The whole thing seems to add verbosity with little gain.
  • I think some attention on nomenclature is in order.  In the libraries Jane Street uses, we have something similar to status (called "result"), but the type is "Ok of 'a | Error of 'b" rather than "Success of 'a | Error of 'b", simply for terseness.  Also, having a function called "result" which converts a "may_fail" into a "status" seems like one name too many.  I would call both the function and the type the same thing (either status or result).  Unless, of course, you want to imply something material about the operation, in which case calling it "eval" or somesuch would make sense.
  • I don't understand why this proposal is only for functional data types.  I didn't find the motivation given in the OSR for this convincing.  I feel like the use of exceptions involves roughly the same tradeoffs when you're using imperative and functional code.  If you have long functional pipelines, doing exception handling at each stage is a pain, much as it is if you do long sequences of imperative operations.  That's why I think the goal should not be for the interfaces to be "exceptionless" so much as to make it easier to keep track of where exceptions might and might not be thrown, so that the reader of a piece of code knows where to stop and worry about exceptions.
y
------=_Part_3233_25419886.1202669225766--