Re: Question on language design (keywords vs Pervasives)

[Pierre Weis <Pierre.Weis@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/