GHC API: expose separate compilation stages

[simonmar]

The GHC API is currently hard to use for certain things: extracting the output from various compilation stages; or "hooking in" to the compilation pipeline. The checkModule function works for some uses, but it doesn't let you extract Core, for example, and it doesn't complete the compilation and inject the result into the Session, so the module still has to be compiled.

One way to solve this would be to abstract the compilation pipeline as a series of functions, so that the user could script the compiler. We haven't worked out the details, but in principle it should be possible to write a GHC API client that invokes the following steps:

• parse a module
• rename/typecheck
• deSugar
• optimise...
• generate code

and can then inject the compilation results back into the Session for use by future compilations. Each individual stage should provide a result that can be inspected: get the renamed/typechecked code out, get the Core, and so on.

The current checkModule could be built on top of such an interface, but the interface would allow much more flexibility.

[claus]

don't forget the output stage(s):-) some people like core, others stg, and i'd like a version of outputable for source that doesn't ignore srclocs in Located.

[Isaac Dupree]

see #1373 for an STG-output request

[nominolo]

We do have separate access to the front-end passes, now. It would be better to have a separate ticket for further access to compiler phases, or requests for improvements in the current implementation. Closing ticket.