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 NAA18367 for caml-redistribution; Tue, 7 Sep 1999 13:33:42 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA08394 for ; Tue, 7 Sep 1999 12:55:36 +0200 (MET DST) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id MAA24489 for ; Tue, 7 Sep 1999 12:55:35 +0200 (MET DST) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id MAA26384 for caml-list@inria.fr; Tue, 7 Sep 1999 12:55:29 +0200 (MET DST) From: Markus Mottl Message-Id: <199909071055.MAA26384@miss.wu-wien.ac.at> Subject: Re: throws To: caml-list@inria.fr (OCAML) Date: Tue, 7 Sep 1999 12:55:29 +0100 (MET DST) In-Reply-To: from "David Monniaux" at Sep 6, 99 07:30:59 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: weis [snip] > The Java language has a nice feature: static detection of exception > leaks (or, more exactly, a conservative and simple approximation of it, > since the full problem is of course undecidable). > That is, functions must declare the exceptions they can throw > (except those generated by the runtime system); exceptions that can be > thrown from function f are inferred by looking at those that can be > thrown > by the functions called from f, those that are explicitely thrown in f > and > those that are caught in f. [snip] This problem very closely resembles the one I once mentioned about declaration/inference of purity (side-effect-free functions): Tagging system- and interfaced C-functions as pure/impure would allow the compiler to infer purity (conservatively since otherwise also undecidable) for any function. This would allow some very interesting optimizations, which would free the programmer from the task of thinking about *when* to evaluate a function (if it is a pure one). Debugging would become easier, too: pure functions never depend on the state of the system so they can be debugged without any consideration of the rest of the code. Are there further (still missing?) features besides detection of exception leaks and purity that could be statically analyzed in a similar way? Regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl