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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 0830BBC0B for ; Wed, 17 Jan 2007 14:18:51 +0100 (CET) Received: from hades.snarc.org (hades.snarc.org [212.85.152.11]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0HDIoiN030979 for ; Wed, 17 Jan 2007 14:18:50 +0100 Received: by hades.snarc.org (Postfix, from userid 1000) id 281ED1B481; Wed, 17 Jan 2007 14:18:02 +0100 (CET) Date: Wed, 17 Jan 2007 14:18:02 +0100 To: Olivier Andrieu Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Ocaml compiler features Message-ID: <20070117131802.GA29382@snarc.org> References: <20070115221717.GA9982@snarc.org> <1168910291.9207.62.camel@rosella.wigram> <20070116090002.GA14494@snarc.org> <1168956872.5332.28.camel@rosella.wigram> <20070116150027.GA17519@snarc.org> <1168969667.5178.18.camel@rosella.wigram> <45AD2672.2090206@gmail.com> <1169004527.8941.77.camel@rosella.wigram> <20070117114104.GA28532@snarc.org> <95513600701170453i28e0fb2scefc39d4774ddaca@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95513600701170453i28e0fb2scefc39d4774ddaca@mail.gmail.com> X-Warning: Email may contain unsmilyfied humor and/or satire. User-Agent: Mutt/1.5.13 (2006-08-11) From: tab@snarc.org (Vincent Hanquez) X-Miltered: at concorde with ID 45AE223A.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 compiler:01 0100,:01 andrieu:01 exn:01 higher-order:01 high-level:01 exn:01 mult:01 mult:01 cheers:01 wrote:01 wrote:01 syntactic:01 exception:01 On Wed, Jan 17, 2007 at 01:53:47PM +0100, Olivier Andrieu wrote: > that's not clear-cut ; it depends on the cleanup function. For > instance, concerning I/O channels in the standard library, you have > close_out and close_out_noerr. They do not have the same behavior, and > you should rather use the _no_err one in the with exn part. You're right it's not clear-cut, but I'm talking about generic code. Some function doesn't have the opportunity to not raise something (without bracing them in try fct () with _ -> ()) and sometimes you also want to propagate the cleanup's fct exception .. because something went very wrong. > >the point is not it's hard to do, it's annoything to duplicate here and > >there, and doing the inline code lose the higher level view we can have > >with a syntaxic sugar like try-finally. > > Just use a higher-order function: it won't duplicate code, it's > high-level and it doesn't require any syntactic sugar. Please read what I wrote before replying. The higher order function is what I do now, because there's no other way for the code I use. It's *not* hard to do and I already have lots of code that just look like your example functions. That said, it's just would be *easier* to express the "concept" with appropriate keyword, not *emulated* through try-with. > let with_file_out fname f = > let oc = open_out fname in > try let r = f oc in close_out oc ; r > with exn -> close_out_noerr oc ; raise exn This one doesn't have equivalent with finally, but that's fine it cannot cover everything. But *most* of the time the cleanup function is similar in both case. > let with_mat m f = > GlMat.push () ; > let r = > try GlMat.mult m ; f () > with exn -> GlMat.pop () ; raise exn in > GlMat.pop () ; > r This become: let with_mat m f = GlMat.push (); try GlMat.mult m ; f (); finally GlMat.pop () I can see in a jiffie what the second function does. It's not as clear with the first one, I need to read a bit more to see what it does (and GlMat.pop has been duplicated) Cheers, -- Vincent Hanquez