Hi folks, 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.) 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. 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. - 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? Cheers, Matthias -- Matthias Neubauer | Universität Freiburg, Institut für Informatik | tel +49 761 203 8060 Georges-Köhler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8052