GHC "extensions" for (pre/post)processors

[pumpkin]

I've been using Conor McBride?'s SHE recently and while it's excellent, error messages produced by code it generates are generally unreadable. This is because the code preprocessor has no opportunity to insert an error post-processor.

What if, instead of SHE being a separate process that GHC ran (and is thus not automatically cabal-installable and so on) on each source file, GHC had a simple extensions interface, where an extension would be a module that contained two functions and a type:

data State = ...

preprocess :: String -> (String, State)
postprocess :: String -> State -> String

GHC would take care of running the preprocessor before doing its own thing, and would preserve the State and pass it back to postprocess the error messages.

This would allow me to write something like {-# EXTENSION Extension.SHE #-} and have it magically produce readable error messages (assuming someone wrote an error postprocessor for SHE).

Of course, since the error messages don't really have a structured format, there'd be no way for these things to compose, since a postprocessor could only make assumptions about error messages it already knows (and not those generated by other postprocessors). But this seems like a fairly low-resistance way to test new features and have them actually be usable without having to know the internals of the desugaring in the preprocessor.

[igloo]

Post-processing could be done just by taking stderr, rather than requiring any GHC support. I don't think it's worth implementing this until someone has actually written such a postprocessor, to show that there is some demand.

I think if you want to do this, you would be better off using the GHC API and getting the errors as a datatype. To really get good errors, you'd probably need to integrate even more closely with GHC.