From: Markus Mottl <mottl@miss.wu-wien.ac.at>
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: <Pine.GSO.4.03.9909061924050.9516-100000@basilic.ens.fr> from "David Monniaux" at Sep 6, 99 07:30:59 pm
[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
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:25 MET