comments on the GHC API

[Matthias Neubauer]

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