Skip to content

GHC "extensions" for (pre/post)processors

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.

Trac metadata
Trac field Value
Version 7.0.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information