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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 2382CBC0B for ; Wed, 17 Jan 2007 04:46:25 +0100 (CET) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0H3kMLK025621 for ; Wed, 17 Jan 2007 04:46:23 +0100 Received: from ppp27-234.lns1.syd6.internode.on.net (HELO rosella) ([59.167.27.234]) by ipmail01.adl2.internode.on.net with ESMTP; 17 Jan 2007 14:16:18 +1030 X-IronPort-AV: i="4.13,198,1167571800"; d="scan'208"; a="74923766:sNHT4885295233" Subject: Re: [Caml-list] Ocaml compiler features From: skaller To: Jon Harrop Cc: caml-list@yquem.inria.fr In-Reply-To: <200701161942.01541.jon@ffconsultancy.com> References: <45A87011.8080203@gmail.com> <20070116150027.GA17519@snarc.org> <1168969667.5178.18.camel@rosella.wigram> <200701161942.01541.jon@ffconsultancy.com> Content-Type: text/plain Date: Wed, 17 Jan 2007 14:46:13 +1100 Message-Id: <1169005573.8941.90.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45AD9C0E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 compiler:01 unboxing:01 mult:01 mult:01 higher-order:01 syntax:01 ocaml's:01 endure:98 sourceforge:01 wrote:01 wrote:01 idiom:01 exception:01 exception:01 On Tue, 2007-01-16 at 19:42 +0000, Jon Harrop wrote: > On Tuesday 16 January 2007 17:47, skaller wrote: > Choosing boxing and unboxing over exceptions is fine if you have that choice > and are willing to endure the performance degredation and added verbosity. > However, you only have that choice if your code is self-contained. If you're > writing a library where users can raise exceptions, you must be careful to > undo state changes. In OpenGL, for example: > > let transform m k x = > GlMat.push(); > GlMat.mult m; > try > k x; > GlMat.pop() > with e -> > GlMat.pop(); > raise e > > could be rewritten: > > let transform m k x = > GlMat.push(); > GlMat.mult m; > try k x finally > GlMat.pop() > > Handling user-raised exceptions in this way is likely if you're using > higher-order functions. Of course any specific example has a work around: let finally u f = try u () with e -> f (); raise e in let u () = GlMat.push(); GlMat.mult m in let f () = GlMat.pop() in finally u f This would, however, be a mess if the push/pop things were nested (which is likely I guess). Felix provides the syntax { code here } meaning Ocaml's (fun () -> code here) which is very convenient for this idiom: finally { push GlMat; mult GlMat m; } { pop GlMat; }; More generally you can write: let f = new thing in let finally () = close f in try ... finally() with e -> finally(); raise e which all gets very messy when you have to repeat the exercise in the 'try' block for some other exception AND in the 'new thing' code as well .. and it's a nightmare if your 'finally()' code can ALSO raise an exception.. ;( -- John Skaller Felix, successor to C++: http://felix.sf.net