Hi Matthias, I think most of what you're asking for is planned... On 17 March 2005 16:59, Matthias Neubauer wrote:

I just had a first look at the sketch for the planned GHC API (ghc/compiler/main/GHC.hs), since we are very keen on using it ...

Our group would mostly like to make use of a compilation manager/module system implementation for Haskell---so these are the parts I concentrated on for now. More specifically, the scenario how we would like to use a GHC library is the following:

So far, we've implemented a static analysis for (single) Haskell modules. To make our tool ready for a wider use, we would like extend it to full Haskell 98 (plus extensions). What we therefore would like to ask a GHC library is, given a specific module A, to compile all the other modules that A is dependent on, load them into a context for A, and start processing A up to the point where the actual type-checking of A would commence. After that, we would like to query the library about the initial (type) environment of A (that is, get out a complete summary of all the imported bindings, classes, methods, etc) to then proceed with our own analysis instead of using GHC's type inferencer.

I see two basic ways how a GHC library could help us to achieve this:

- The library both offers a separate module dependency analysis and also lets us use the compiler in one-shot mode. We then could first calculate the dependencies of A, compile them separately, and calculate the initial environment of A manually by combining the interfaces of the imported modules. Of course, we would also need the possibility to access the imports of A (including renamings and such) without the need to compile A as a whole.

- Loading a set of targets (using *load*) can be controlled in a more fine-grained way. Instead of just offering the possibility to compile a set of targets either completely or not at all, there is an option to compile targets only up to a certain compilation phase (or alternatively, to optionally keep intermediate results occurring between the phases to be able to retrieve them afterwards.)

The 'load' function lets you load only up to a certain module, and the JustTypecheck mode stops before code generation and lets you inspect the typechecked code. Using this, you can compile one module at a time and get the typechecked code out - does that sound ok? There are some areas to do with getting access to the typechecked class declarations and some other parts of the module that we have still to sort out. The refactoring folks also want access to the renamed code (before typechecking), which includes more of the original declarations.

We, for our part, would need parts of the intermediate result (that is, the type environment and class declarations) existing either before parsing A, after parsing A, or, even better, after renaming A. Other users may be interested in other intermediate results.

What do others think?

Some more, rather random, remarks:

- I guess v_CmdLineMode and friends are iorefs that are supposed to live globally in GHC.hs. Couldn't you also pack them into a separate data type created by *init* and later share them between several sessions.

The CmdLineMode will be private to the front end only, but there's a related GhcMode that now lives in the DynFlags. Take a look at the HEAD as it is now (I just commmitted some big changes in this area in preparation for the GHC API).

Maybe we could even introduce a Session monad? Looking at all the functions again, they all seem to have Session arguments ...

- I guess the exported name *GhcSession* should read *Session* (or better the other way around)

- Same for *GhcMode* vs. *GhciMode*

- What's the purpose of having a mode argument for "newSession"? As I read the rest of the API, *load* is the only way to trigger the compilation of targets. And *load* seems to be intended to work similar to the interactive mode only.

load might compile and link object code in --make mode, or compile and dynamically-link bytecode in --interactive mode.

- What are Module, ModSummary, ModIface, HsTypecheckedGroup, HsGroup, TyThing, and Type standing for (I know of course ...)? How complicated would it be to return already existing (TH) data types instead of exposing/specifying more of GHC's internals?

The TH types aren't really rich enough for all the purposes we expect this interface to be used for. In particular, the data type needs to include the full GHC language, it needs to include full source location information (the refactoring folks need this, and so does Visual Studio), and it needs to include type information for identifiers. Only HsSyn includes all this. Cheers, Simon