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=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 0F69DBC6C for ; Tue, 5 Feb 2008 12:39:03 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACrZp0fAXQInh2dsb2JhbACBWI5TAQEBCAopnA4 X-IronPort-AV: E=Sophos;i="4.25,307,1199660400"; d="scan'208";a="6910100" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 05 Feb 2008 12:39:02 +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 m15BcwJP031499 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 5 Feb 2008 12:39:02 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FACrZp0fCTtud/2dsb2JhbACBWKsf X-IronPort-AV: E=Sophos;i="4.25,307,1199660400"; d="scan'208";a="6910097" Received: from 157.219-78-194.adsl-static.isp.belgacom.be (HELO decis.be) ([194.78.219.157]) by mail2-smtp-roc.national.inria.fr with ESMTP; 05 Feb 2008 12:38:58 +0100 Received: from [192.168.0.30] by decis.be (MDaemon PRO v9.6.3) with ESMTP id md50001985744.msg for ; Tue, 05 Feb 2008 12:36:44 +0100 Message-ID: <47A84A50.6080602@decis.be> Date: Tue, 05 Feb 2008 12:36:48 +0100 From: =?ISO-8859-1?Q?Fr=E9d=E9ric_van_der_Plancke?= User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: caml-list@inria.fr Subject: Re: [Caml-list] [OSR] Exceptionless error management References: <1202205644.6226.5.camel@Blefuscu> <20080205101221.GA3922@snarc.org> <9A13D5E1-E455-4019-B0BA-D8D7DD4CE49E@erratique.ch> In-Reply-To: <9A13D5E1-E455-4019-B0BA-D8D7DD4CE49E@erratique.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-Sender: fplancke@decis.be X-MDRemoteIP: 192.168.0.30 X-Return-Path: fvdp@decis.be X-Envelope-From: fvdp@decis.be X-MDaemon-Deliver-To: caml-list@inria.fr Reply-To: fvdp@decis.be X-MDAV-Processed: decis.be, Tue, 05 Feb 2008 12:36:46 +0100 X-Miltered: at concorde with ID 47A84AD2.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; plancke:01 bunzli:01 variants:01 pervasives:01 pervasives:01 entail:01 polymorphic:01 wrote:01 caml-list:01 variant:02 frederic:03 frederic:03 daniel:04 inria:06 long:06 Bünzli Daniel wrote: > Still I think this is a little bit sad. Using polymorphic variants > isn't that bad at all as long as we just use the following _closed_ > type [ `Value of ... | `Error of ... ]. This would allow us to move > forward despite that fact that Pervasives is frozen (and no I'm not > interested in forking it). But Pervasives is not *that* frozen. If I understand things well, the main concern of Inria is having to maintain the would-be additions and changes to Pervasives. An Ok | Error variant doesn't look like it will entail heavy maintenance charges. So they may accept to add it. (I don't think there are backwards-compatibility problems either as user-defined Ok|Error would hide a Pervasives-defined one in all contexts I can think of.) Frédéric