comments on the GHC API

[Simon Marlow]

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