Proposal: Extensible exceptions

[Duncan Coutts]

On Fri, 2008-07-18 at 13:17 -0400, Brandon S. Allbery KF8NH wrote:
> On Jul 18, 2008, at 12:04 , Duncan Coutts wrote:
> > On Fri, 2008-07-18 at 11:19 -0400, Brandon S. Allbery KF8NH wrote:
> >> I'm going to ask a possibly silly question:  has anyone thought about
> >> this vis-a-vis Simon's proposal of a new signals API?  It's not that
> >> unusual for signals (usually SIGUSR1/SIGUSR2, often SIGINT, SIGHUP,
> >> sometimes SIGABRT, SIGQUIT) to be used as asynchronous triggers ---
> >> which might be best represented in the "Haskell world" as special
> >> exceptions.  Likewise, it often makes sense to treat SIGPIPE, SIGHUP,
> >> SIGINT as exceptions instead of signals.
> >
> > SIGINT will be an exception in ghc-6.10. It will throw an async
> > exception to the main thread. We're just trying to think of the  
> > details
> > though, eg how to programs like ghci ignore ^C and can it be done in a
> > portable way.
> >
> > SIGPIPE can be ignored because we get a sync exception when we write  
> > to
> > a pipe with no reader.
> 
> I think I was more getting at (a) reserving an exception "class" for  
> remapped signals,

What do you mean exactly?

> and (b) optionally providing a convenience function to install a
> signal handler for a given signal that maps it to the equivalent
> exception.

That's pretty trivial, one line of code:

addSignalHandler sigWHATEVER $ \_ -> throwTo threadid exception

I'm not sure it's worth adding anything special.

Duncan