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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id C4E44BC6B for ; Sun, 10 Feb 2008 13:35:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABR+rkfAXQImh2dsb2JhbACQNwEBAQgKKZVx X-IronPort-AV: E=Sophos;i="4.25,329,1199660400"; d="scan'208";a="22442802" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 10 Feb 2008 13:35:15 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m1ACZEXM007341 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sun, 10 Feb 2008 13:35:15 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMh+rkfUVZgL/2dsb2JhbACmZQ X-IronPort-AV: E=Sophos;i="4.25,329,1199660400"; d="scan'208";a="7868372" Received: from hades.snarc.org ([212.85.152.11]) by mail1-smtp-roc.national.inria.fr with ESMTP; 10 Feb 2008 13:35:14 +0100 Received: by hades.snarc.org (Postfix, from userid 1000) id D28491B482; Sun, 10 Feb 2008 13:35:12 +0100 (CET) Date: Sun, 10 Feb 2008 13:35:12 +0100 To: =?iso-8859-1?Q?B=FCnzli?= Daniel Cc: caml-list List Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2 Message-ID: <20080210123512.GB11897@snarc.org> References: <1202396482.6084.5.camel@Blefuscu> <20080208.001729.233402575.garrigue@math.nagoya-u.ac.jp> <20080208095333.GA582@snarc.org> <1202467938.47ac3462d077a@imp.free.fr> <20080208115635.GA2885@snarc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Warning: Email may contain unsmilyfied humor and/or satire. User-Agent: Mutt/1.5.16 (2007-06-11) From: tab@snarc.org (Vincent Hanquez) X-Miltered: at discorde with ID 47AEEF83.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0100,:01 bunzli:01 semantics:01 compiler:01 compiler:01 polymorphic:01 polymorphic:01 wrote:01 unix:01 unix:01 integer:01 integer:01 caml-list:01 variant:02 variant:02 On Fri, Feb 08, 2008 at 01:40:09PM +0100, Bünzli Daniel wrote: > Only if they have exactly the same error cases (in which case they are very > likely to attach the same semantics to it). I think you fail to think > realisitically, chances are little that this is going to pose any problems > in practice. with growing use of polymorphic variant everywhere, like lots of people suggest, i can see the number of "collision" raising quickly. specially defining for regular usage stuff like `Error `Succeed, very common stuff. > Do you redefine the option type in each of your modules to be > able to say this is an optional integer from module X ? no, for the simple reason that the option type is (almost) a built-in type. it could be abuse yes, but everyone knows it's a shared type. like integer or string. the "integer 1" is the same in every module, the "error of integer 1" is probably different. for example, in unix: "Error of 1" would means EPERM in xml: "Error of 1" would means error line 1. If you working with normal variant, the compiler knows it can't compare Unix.Error and Xml.Error even though they have the same type attached (an integer). with polymorphic variant, there's only "`Error of integer" in both module, so for the compiler they are the same. >> If I use normal variant, the compiler will prevent me using the same code >> to match a X.Error and a Y.Error. > > Note that with this take 2 proposal -- that I personnaly find too invasive > and heavy weight -- you won't get that, you will have to match on > Error.Error (!) instead of `Error (take 1). it all boils down in where the thing is going to end up or how it's going to be use. -- Vincent Hanquez