[EMAIL PROTECTED] (Greg Michaelson) writes:
> In SML(sorry...), in: <exp1> handle <exp2>
> <exp1> is evaluated and any exception raised within it is handled by an
> appropriate handler in <exp2>. If there isn't one then the exception
> is handled in the enclosing environment for the whole construct. Similarly,
> if an exception is raised in <exp2> then it is handled in the enclosing
> environment. So exception handling follows a stack based regime.
>
> Instead, how about having <exp2> handle exceptions raised within itself
> and also allowing mutually recursive handlers?
No need to wire this into the semantics/implementation - it's easy
to implement your "recursive catch" using the plain catch:
rcatch :: IO a -> (IOError -> IO a) -> IO a
m `rcatch` h = m `catch` \err -> (h err `catch` h)
but notice that I call plain catch when invoking the handler - so
we won't get into infinite loops.
If infinite loops are what you want :-), then we have "really recursive catch"
rrcatch :: IO a -> (IOError -> IO a) -> IO a
m `rrcatch` h = m `catch` \err -> (h err `rrcatch` h)
Yet another variant would be to invoke the handler up to 10 times (say)
before giving up and invoking the outer handler.
> This might form a very
> nice inter-process communication mechanism, which may be recognised
> by people who have written interrupt driven multi-process systems.
I sort of see how this might work - but I've only _read about_ such systems
- not actually implemented them. Where could I find out more?
Alastair
ps I'm getting kinda worried about people talking about using the
exception handling mechanism to implement various control constructs.
While our non-deterministic semantics is (I hope) fine for writing
robust programs, I can't see how to build __predictable__ control
constructs on top of it and I have no desire to modify the implementation
and semantics just so that you can do so.
I also think we need to spend some time playing with the GHC-based
implementation before we'll really know how it performs. Just how big
a problem will it be if an optimiser transforms a program that would have
raised an error into a program that enters an infinite loop and triggers
a timeout? In some applications, this won't be a problem but it could
be a real problem in others.
