Fergus Henderson <[EMAIL PROTECTED]> points out that our exception handling
scheme hits problems if you hit an infinite loop instead of an exception.
Yes, this is a problem - and not a pretty one.
Fixes:
1) Remove fixpoints so that infinite loops don't happen.
Ok, so this isn't really an option - but it's worth mentioning
because even this isn't enough! The problem is that our
optimiser might rearrange code so that we run out of heap
instead of hitting an error.
2) Solve the halting problem.
See (1).
3) Add timeouts (and ctrl-C handling) into the mix - practical
approximations to solving the halting problem.
Actually, all we really need is Concurrent Haskell and the ability
to kill threads. (Being able to suspend a thread would probably
be useful too.) The new GHC-Hugs runtime system will have both.
Fergus then lists a bunch of options and says:
> Of these options, I'm afraid that (a), the status quo, is looking to me
> like the best of a bad lot, albeit with (c) (i) a close second.
You're welcome to do that and we certainly aren't going to try to add
exception handling to any kind of standard before we have lots of
experience of how well it works in practice.
(Though it would be nice if all Haskell implementations happened to
have a compatible "non-standard" exception handling mechanism :-) )
But some of us have to write programs that keep working. For example,
I'm busy hacking on our Robo-Haskell code at the moment - it just isn't
acceptable for that kind of code to print an error message and halt.
I remain convinced that:
Haskell will remain a toy language until it can be used to write
robust programs.
As far as I can see, that means we either have to eliminate pattern
match failure, the error function, heap overflow, stack overflow
and infinite loops or we have to add exception handling in some form.
Alastair
