comments on the GHC API
neubauer at informatik.uni-freiburg.de
Thu Mar 17 11:58:31 EST 2005
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
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?
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
More information about the Glasgow-haskell-users