comments on the GHC API

[Matthias Neubauer]

"Simon Marlow" <simonmar at microsoft.com> writes:

> I think most of what you're asking for is planned...

Great to hear!

[...]

> 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?

That sounds perfect, except that ...

> 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 also need the state after renaming, but we then have to stop, I
suppose!

Because we want to do do our own typechecking, stopping after ghc's
typechecking would be to late: in case of a type error, ghc falls back
into the wrong context (at least that's what's happening right now when
doing a :load inside ghci ...).

>>   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.

Is there a way to get access to all the identifiers that are
*imported* into the current module? Having that piece of information
at hand, we could then use *lookupThing* to cumulate the initial type
environment and the initial class environment for our analysis.

Or do you see another/better way of doing that?

-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
>  LocalWords:  tel