[m-dev.] for review: add extras/exceptions

[Peter Schachte]

On Wed, 22 Jul 1998, Fergus Henderson wrote:

> Incidentally, with the current implementation the behaviour will
> actually be to jump to nearest enclosing handler.  The trouble is
> just that you get resource leaks. 
...
> But the other kind of resource that leaks is resources allocated in the
> C code that threw an exception over -- this can include malloc()ed
> memory, file descriptors, and other OS resources.  The fix for this is
> not nearly so simple.  I think the only solution to that would be to
> change the C interface so that e.g. semidet Mercury procedures return
> an enum { Succeed, Failed, GotException } instead of bool.
> And this would also have potentially significant overhead, I think --
> every call from C to Mercury would need to do a catch, basically.
> 
> Another alternative would be to provide some way for C code to
> catch Mercury exceptions, by exporting a version of `try_io' to C.

How about using the function trail?  This way the overhead is only paid by
code that has resources it needs to protect (once the overhead of having a
trail is paid).

> (Fixing the limitation would require adding new builtin types
> `impure pred', `impure pred(T)', which is clearly a language extension...)
> 
> But it's not related to exception handling as such, so it should be a
> separate change.  I'm hoping that Peter Schachte will do this one ;-)

I'd love to, if I get the time.  Maybe while we're complicating the pred
types would be a good time to add the concept of a one-shot closure:  a pred
that will be executed precisely once.  Such things could sensibly have
curried output arguments.  Is that on the wish list, BTW? 


-Peter Schachte               | One thing's for sure: if we keep doing what
mailto:pets at cs.mu.OZ.AU       | we're doing, we're going to keep getting
http://www.cs.mu.oz.au/~pets/ | what we're getting.
PGP: finger pets at 128.250.37.3 |     -- Stephen Covey, et al.