PreTraceHook, PostTraceHook and ErrorHdrHook hooks in RTS

[Simon Marlow]

> My proposal is to replace the hooks:
> 
> void PreTraceHook(long fd);
> void PostTraceHook(long fd);
> void ErrorHdrHook(long fd);
> 
> with the general hooks:
> 
> void TraceHook(char *msg)
> {
>    fputs(msg, stderr);
> }
> 
> void ErrorHook(char *msg)
> {
>    fprintf(stderr, "Fail: %s", msg);
> }
> 
> I am waiting forward to your comments and proposals.
> If you accept the idea, I will be happy to implement
> it.

Let's take these seperately:

(1) ErrorHdrHook: yes.  Most of the contents of writeErrString__ (in
    libraries/base/cbits/writeError.c) can be replaced by a hook,
    which looks like a good idea.  This affects the top-level
    exception handler for a program and the top-level exception
    handler for concurrent threads.

    Perhaps on Windows, for a program that is compiled with -mwindows(?)
    we should link in a version of ErrorHook that pops up a MessageBox
    instead of using stderr (and fix all the other places that the
    RTS relies on having stdout/stderr...).

(2) TraceHook: I'm not so sure about this.  In my opinion, it's fine
    for trace to be defined as outputing to stderr:

       trace s e = unsafePerformIO (hPutStr stderr s >> return e)

    but an application should use its own version of trace if needs be.
    (eg. in GHC we should use our own version of trace which might
    use the debug console on Windows).  IMO we should get rid of
    PreTraceHook and PostTraceHook.

    The difference between this and the ErrorHook is that the programmer
    has the option to call a different trace, but the programmer
    has no control over what's used for the top-level exception handler
    in the program, so it makes sense to allow the use of a hook there.
    trace shouldn't be used by library code.

Cheers,
	Simon