comments on the GHC API
neubauer at informatik.uni-freiburg.de
Tue Mar 22 12:48:41 EST 2005
"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
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 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
More information about the Glasgow-haskell-users