invoking front-end phases from within a GHC plugin?

[Nicolas Frisby]

I'd like to generate new declarations/bindings from within a GHC plugin. My
current concrete goal is just to add a new vanilla data definition, but
long-term it could be more open-ended. Crucially, these new declarations
will reference variables bound by the original module and its imports.

Long-term, it'd be nice if we could invoke the parser/renamer/typechecker
in order to do so. Broadly, the required plumbing seems doable. I wrote a
custom initTc that initializes the TcGblEnv from the ModGuts that the
plugin receives. This is enough to invoke the
renamer/typechecker/desugarer. The resulting new ModGuts can then be merged
into the original ModGuts, perhaps after some Simplification.

Has anyone explored/designed down this path? I've got some questions about
a snag I hit.

Parsing seems fine (superficially) but the renamer fails. I'm re-using the
global Rdr environment from the plugin's input ModGuts, so that free vars
from the new syntax will reference other bindings in the original module
and its imports. However, that environment is keyed on the uniques of
FastStrings, ultimately raising "name not found" errors.

This happens because the global variable for the FastString Table is not
being shared between the actual compiler and the new image of the GHC
library that the plugin is using. One solution seems to be including the
FastString Table in the  "reinitializeGlobals" mechanism. This would
require a GHC patch.

Questions:

1) Was the FastString Table intentionally left out of the
reinitializeGlobals mechanism?

2) Are there similar obstacles lurking beyond this one that people know
about? How incompatible is the invocation of front-end phases wrt the
current plugin architecture?

My design assumes the HscEnv and ModGuts received by the plugin include
enough information to reconstruct a meaningful TcGblEnv representing the
original module. This seems to be at least nearly true. I am, however, not
very well-versed with how imports are handled (EPS and such), so I don't
know if the FastString Table issue is just the tip of the iceberg.

Thanks for your thoughts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130620/f1a4782b/attachment.htm>