From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA04472 for caml-red; Mon, 21 Aug 2000 23:29:31 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA04350 for ; Mon, 21 Aug 2000 23:24:52 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e7LLOmf20183; Mon, 21 Aug 2000 23:24:48 +0200 (MET DST) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA05094; Mon, 21 Aug 2000 23:24:47 +0200 (MET DST) From: Pierre Weis Message-Id: <200008212124.XAA05094@pauillac.inria.fr> Subject: Re: Question on language design (keywords vs Pervasives) In-Reply-To: <39A15C69.D2A3A9B9@maxtal.com.au> from John Max Skaller at "Aug 22, 100 02:44:25 am" To: skaller@maxtal.com.au (John Max Skaller) Date: Mon, 21 Aug 2000 23:24:47 +0200 (MET DST) Cc: caml-list@inria.fr X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: weis@pauillac.inria.fr > I'm not sure I agree with that. If raise is the _standard_ > way to raise an exception, then it _should_ be rebindable (and be > defined in terms of a more primitive function). I'm sure that there is no ``more primitive function'' than raise to raise an exception. So sorry, you cannot define raise ``in terms of a more primitive function'' in Caml. You would need a language with call/cc to express that, and Caml is not this language. > The reason is precisely to permit hooking it by the user, which is > an extremely common requirement. > For example, to introduce some extra logging. Nobody never asked for that for more than 9 years before raise has been turned into a regular ident to save 2 lines in the Caml parser. So, no, this is not ``an extremely common requirement''. > In C++, exceptions are raise by a keyword 'throw', and it > is a pain, because good practice dictates NOT to ever raise an > exception directly with 'throw', but to call a (template) function > usually defined to simply raise the exception (using throw). > This permits replacing the function to, for example, print an > error message to stderr, as well as throwing the exception. > The problem is, this doesn't work for any third party code, > or even one's own code, if the idea occurs to one belatedly. > > -- > John (Max) Skaller, mailto:skaller@maxtal.com.au > 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 > checkout Vyper http://Vyper.sourceforge.net > download Interscript http://Interscript.sourceforge.net There is a confusion here: Objective Caml is not C++, despite the Objective qualifier: there is no template in the language, so you cannot use them for exceptions. Also remember that in Caml exceptions are used in common programming situations where raising an exception is not an error but a success: for instance, one commonly raises the predefined exception Exit to exit from a while loop, or raises a user's defined exception to jump out and carry the final result of an expression (e.g. if Break has type int -> exn, you can raise (Break v) to exit from a for loop, returning the integer result v to the surrounding try with). The tracing mechanism you described would be strange in this kind of situation. Also, the exception tracing problem solved by this kind of hacks is handled more cleanly and elegantly by the replay debugger of Objective Caml, that permits to go back to the point where the exception has been raised and to examine the local environment. On the other hand, you can use the same encapsulation techniques in Caml and to define and use specialized functions to raise specialized exceptions, and this is considered good practice (e.g. predefined exception raisers invalid_arg or failwith). I was just arguing the usefulness of being able to redefine the meaning of raise to something unrelated to raising exceptions, I was not un any extent proposing to restrict the use of raise into whatever function you need to; I agree with you on this point, we want to be able to define specialized exception raisers. I was just saying that (to me) the program fragment if x = 0 then raise (Division_by_zero) else 1 / x should raise the exception Division_by_zero, when x = 0 is verified. I would be glad if Caml could ensure that property in any context. Conversely, I would consider it as an undesirable feature if this expression could return something else in some context; for instance, because somewhere raise has been rebound as a constant polymorphic function: let raise _ = 1;; Pierre Weis INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/