My own priority is to have the compilation phases exposed. One (selfish) reason for this is that it will force a number of refactorings and cleanups inside GHC, that we've had on the radar for some time. As soon as there's a wiki page up I can start downloading some of the contents of my whiteboard onto it :-)
This aspect is going to affect my own project, GHC plugins. Plugins need to be able to register their own compilation phases and when they should be run with the compiler. A nice way to do this might be to encode the current GHC stage inter-dependencies in code. Plugins could then add their own stages with similar dependency information and finally GHC would compute a topological sort based on the constraints as the actual order in which to run stages. These codified dependencies would complement any documentation based approach. I sketched a very rough idea of what that could look like at http://hackage.haskell.org/trac/ghc/wiki/Plugins (see note [Declarative Core Pass Placement]). I don't have the bandwidth to seriously think about these issues until after exams, but there are other things GHC-API related things that need to happen for plugins: - Expose the Core representation with documentation - Expose and document internal functions for manipulating Core (e.g. CoreUtil, DsUtil) I'm happy to do this work myself, but I need to be sure it's relatively coordinated with Thomas' work and the intentions for the compiler passes so we don't step on each others toes. Cheers, Max