From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 A239BBC57 for ; Thu, 27 May 2010 11:30:08 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskDAO/Y/UtRZ90wkWdsb2JhbACeGBUBAQEBCQsKBxEDH8AahRME X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; d="scan'208";a="63502914" Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]) by mail4-smtp-sop.national.inria.fr with ESMTP; 27 May 2010 11:29:34 +0200 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100527092933.RQFX10460.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Thu, 27 May 2010 10:29:33 +0100 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20100527092933.LKUG1598.aamtaout03-winn.ispmail.ntl.com@romulus.metastack.com>; Thu, 27 May 2010 10:29:33 +0100 Received: from Tenor ([212.183.140.35]) (authenticated bits=0) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id o4R9TKUr014372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 May 2010 10:29:25 +0100 From: "David Allsopp" To: "'Mark Shinwell'" , "'David Allsopp'" Cc: "'Florent Ouchet'" , References: <956439.81564.qm@web111506.mail.gq1.yahoo.com> <4BFE2881.1070705@imag.fr> <000c01cafd7a$3f6595e0$be30c1a0$@romulus.metastack.com> <20100527091110.GD18772@janestreet.com> In-Reply-To: <20100527091110.GD18772@janestreet.com> Subject: RE: [Caml-list] Static exception analysis or alternative to using exceptions Date: Thu, 27 May 2010 10:29:20 +0100 Message-ID: <001901cafd7f$19d7afc0$4d870f40$@romulus.metastack.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIBUroxhHU31Hf1sNIRcTuhV5nPKgI6/bv5Ah5T7dsDCni87wHoK2MsAiVzki4BpeZlVg== Content-Language: en-gb X-MSL-Actually-To: dra-news@metastack.com Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77 X-Cloudmark-Analysis: v=1.1 cv=1ggfb5FlKZQUfF3vzm9UBYZ2uTfLsbs/8dSljwg5+mE= c=1 sm=0 a=TkWsxXdVWLYA:10 a=Lw_SFsgOoS4A:10 a=8sW17jYxVu0A:10 a=kj9zAlcOel0A:10 a=-7hNRWVj5LzQvlpQjmsA:9 a=ZzLzGbLWgODY9-TrAU0A:7 a=YWqmp0EitTGIbwSYez8VWoY1R38A:4 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Spam: no; 0.00; shinwell:01 0100,:01 hashtbl:01 popping:01 compiler:01 exn:01 variants:01 unreadable:01 hashtbl:01 hacks:01 imho:01 wrote:01 wrote:01 exception:01 exception:01 Mark Shinwell wrote: > On Thu, May 27, 2010 at 09:54:29AM +0100, David Allsopp wrote: > > Florent Ouchet wrote: > > > Same here, specially to avoid the Not_found exception. > > > The optional return values gives the oportunity to have a clear view > > > of what is being done if the result is not available. > > > > Agreed - though [find] is one of the examples where you do need find > > and find_exc - because often there are occasions where before calling > > {Map,Set,Hashtbl}.find you already know that the key exists and so > > won't fail at which point the 'a option boxing is a waste of time and > > space and Not_found would be a truly exceptional situation so passes > > the previously mentioned test. > > I don't think I agree with this. I would argue that for the majority of > programs it is likely that the extra overhead is in fact negligible. In > the cases where it should be impossible to get the None return value, I > think that should probably be annotated as such in the code with "assert > false", which would seem to be more appropriate than a random Not_found > popping up at some much higher level. assert false is just a way of renaming the exception and relies on the rather dirty (but necessary) hack in the compiler that, as a special case, assert false is not optimised out of a program compiled without debugging checks. > Whilst I agree that there are arguments relating to verbosity of the use > of option types, I think the strongest argument for keeping the *_exn > variants may actually be that they're just a lot more convenient for quick > hacks. Unnecessary verbosity = unreadable IMHO, that's one of the reasons we use clear, functional languages in the first place. That overhead also isn't negligible as soon as you've got a Hashtbl/Set/Map which is queried a lot (i.e. just about any form of data processing). Code where you know a priori that the keys exist becomes unnecessarily peppered with pointless match clauses (or calls like ExtLib's Option.get which... would raise an exception if faced with None!). The interest to me is not that the overhead is negligible, but that it can be trivially removed by using a *better* function in that instance. Obviously, in the perfect world, your call to the _exc version would in reality carry a proof that the key will be found (and so no exception would be necessary). I simply don't see that the overarching reason to have the _exc version of the function would be simply for hacking a quick solution to a problem where you can't be bothered to handle the Not_found case. David