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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id DF424BC0A for ; Mon, 11 Dec 2006 14:11:16 +0100 (CET) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id kBBDBGjo027701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Dec 2006 14:11:16 +0100 Received: from courriel.upmc.fr (courriel3.reseau.jussieu.fr [134.157.0.194]) by shiva.jussieu.fr (8.13.7/jtpda-5.4) with ESMTP id kBBDAwF1035629 for ; Mon, 11 Dec 2006 14:10:59 +0100 (CET) X-Ids: 164 Received: from etu.upmc.fr (localhost [127.0.0.1]) by courriel.upmc.fr (8.13.6/jtpda-5.4) with ESMTP id kBBDAnEY049572 for ; Mon, 11 Dec 2006 14:10:57 +0100 (CET) Received: from out-of.ilog.fr (out-of.ilog.fr [81.80.159.49]) by webmail.etu.upmc.fr (Horde MIME library) with HTTP; Mon, 11 Dec 2006 14:10:49 +0100 Message-ID: <20061211141049.fnuvnyhgcggwswow@webmail.etu.upmc.fr> Date: Mon, 11 Dec 2006 14:10:49 +0100 From: Diego Olivier FERNANDEZ PONS To: caml-list@inria.fr Subject: Re: [Caml-list] Today's inflamatory opinion: exceptions are bad References: <004501c71c40$b52e8d00$15b2a8c0@wiko> <17788.2858.414320.138285@serveur9-10.lri.fr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Virus-Scanned: ClamAV version 0.88.5, clamav-milter version 0.88.5 on shiva.jussieu.fr X-Virus-Scanned: ClamAV 0.88.4/2315/Mon Dec 11 10:55:24 2006 on courriel3.reseau.jussieu.fr X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (shiva.jussieu.fr [134.157.0.164]); Mon, 11 Dec 2006 14:10:59 +0100 (CET) X-Miltered: at discorde with ID 457D58F4.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Miltered: at shiva.jussieu.fr with ID 457D58E2.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; pons:01 pons:01 backtracking:01 sub-optimal:01 erlang:01 o'caml:01 backtracking:01 pointer:01 overwritten:01 computations:01 ocaml:01 recursion:01 structurally:01 structurally:01 usefull:01 Bonjour, Quoting Haoyang Wang: > ML was designed for theorem provers, and many of its features can be > traced back to that specific purpose. I read somewhere that exception > was introduced in ML for back-tracking, which occurs frequently during > the normal course of trying out various tactics to prove a theorem. I heavily use exceptions for backtracking in combinatorial =20 optimization (actually it is a combination of exception raising and =20 lazy values). Same as for theorem provers, when a branch is proved sub-optimal it is =20 abandoned. > With automatic memory management, there is less need to clean up after > an exception. Thus exceptions can be used quite freely in both Erlang > and o'caml. The exception based backtracking can be coupled with a garbage =20 collector that on backtrack only moves the current pointer back (the =20 abandoned memory is just overwritten by the subsequent computations). =20 This is traditional in high performance combinatorial optimization =20 languages/frameworks/engines. Quoting Brian Hurt: > I think I've come to the conclusion that exceptions are bad. > In Ocaml, they're useless in many cases, and in most cases wrong. I believe you have only shown that IO in the standard library has a =20 poor design and that [try ... with] may be a bit too simple to handle =20 all the useful cases (confer to Martin Jambon's extension). I =20 completely agree for both points. > There's one other use for exceptions I've seen (and done)- using them as > non-local longjmps. A classic example for this is a delete functions on a > tree structure- you recurse all the way down to the leafs and discover tha= t > you're not deleting anything at all, what do you do? I sometimes =20 > (too often) throw an exception to jump out of the recursion back up =20 > to the > top level. Apart from performance (because of the garbage collector being less =20 stressed) that idioma has a few good properties like ensuring that two =20 physically different versions of your tree are structurally different. =20 In this specific case it only works at depth one (you can add the =20 element back and end with two physically different trees that are =20 structurally equal). But the technique is usefull for limiting memory =20 consumption, ensuring uniqueness or implementing hash-consing and =20 related. Diego Olivier