[mercury-users] Exceptions (again!)

[Fergus Henderson]

On 16-Jul-1998, Ralph Becket <rwab1 at cam.sri.com> wrote:
> Looking over the reference manual, I notice that exceptions are still
> not part of the language.  Fergus posted a patch to provide
> exceptions, but said that there were problems with the semantics.  I
> can see that, but I was wondering whether the debate had moved on?

I think it is fair to say that some progress has been made.
I've continued my attempts to better understand the semantics
of exception handling, and I think I have a reasonable handle on it now.
(I'm currently writing a paper on exception handling in Haskell.)

> But if exceptions really are too horrible for words, could somebody
> explain to me why?

Well, one issue is that unless you nail down the operational semantics
more tightly than we want to, if evaluation of a computation could raise
more than one exception then it will be unspecified which one you get.
Even simple things like `throw, fail' may have unspecified behaviour if
you want the compiler to be able to reorder conjunctions.  And even if
you do nail down the operational semantics, you don't want the
declarative semantics to depend on the operational semantics, as would
be the case with the obvious way of modelling exception handling.

However, now that we have committed choice nondeterminism in Mercury,
we won't have any difficulty modelling that one.  So that issue is
no longer a problem.  That is the sense in which progress has been made.

The remaining issue -- the one convinced me to put the issue of
exceptions in Mercury aside for a while -- is the interaction
with unique modes and destructive update.  The combination of
destructive update and exception handling is a real problem,
as the C++ community has recently discovered.  The question is,
if you do destructive update on an object and then throw an exception,
what value will the object have when the exception is caught?
Sometimes you want full commit-or-rollback transaction-like semantics,
where the effects are completely undone on backtracking (either by
trailing any updates as you go, or by making a copy of the object before
you start the operation).  But often this is infeasible (e.g.
if the object is the io__state) or just plain too expensive.

The issue is made more difficult because Mercury has a value-oriented
semantics rather than a state-oriented or object-oriented semantics, so
you can't even really talk about "the current state of the object";
instead, you just have values, which may be either live (referenced) or
dead (in which case their storage may have been reused).  A compiler
that supported compile time garbage collection and structure reuse
might decide to reuse the storage of a dead object to hold a value of a
completely different type.  So allowing compilers to do that would rule
out any kind of semantics where such objects have their value retain
whatever "current state" it had at the time the exception was thrown.

So, the worry is that if we add exception handling support now, before
we have implemented support for structure reuse, and particularly if we
make significant use of it in the standard library, we may be tying our
hands when it comes to implementing structure reuse in the future.
This would not necessarily be the case, but for the time being our
decision was to just remain cautious.

That said, it would be quite possible to provide an exception handling
interface that just did not allow any unique modes to cross the point
where an exception is caught, so that the issue of destructive update
is moot.  The only real worry with this is that if people use it, then
they may end up not being able to take advantage of structure reuse and
destructive update later on.

Actually you'd need two versions, one which didn't allow any unique
modes, and one which allowed only the io__state.  The io__state is
special, in the sense that there is only one such state, and
when you use it you really can consider it as state-oriented
(i.e. imperative) programming.

Anyway, given the advantages of waiting until we have more support
for structure reuse and destructive update, and given the number 
of other exciting projects on the go at the moment, this is not
our highest priority.

Cheers,
	Fergus.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.