I hadn't, thanks for the pointer. At first glance, the methodologies look distinct, however. My use case does not involve metaprogramming per se. Thanks again for the response though; looks like an interesting project to track. On Jun 26, 2013 2:44 AM, "Carter Schonwald" <[email protected]> wrote:
> This sounds somewhat complementary to some of the Template Haskell work > being done by Geoff Mainland to support Manuel's Inline Objective C style > template haskell machinery. Have you looked at that work at all? Sounds > like there might be some overlap! > > > > On Mon, Jun 24, 2013 at 10:56 PM, Nicolas Frisby <[email protected] > > wrote: > >> Just a quick update: I patched a local copy of 7.6.3 to add >> FastString.string_table to the CoreMonad.reinitializeGlobals mechanism. >> After that change, I can invoke the front-end >> (parser,renamer,typechecker,desugarer) from within my plugin on a simple >> example. >> >> Original module: >> >> > module Test where >> > >> > data X = X Int Int >> >> Syntax parser from within the plugin: >> >> > data Y = Y X X >> > f (Y (X a b) (X c d)) = a + b + c + d >> >> Perhaps this simple example is luckily avoiding some nasty pitfalls, but >> it seems to be working. >> >> >> On Thu, Jun 20, 2013 at 11:27 AM, Nicolas Frisby < >> [email protected]> wrote: >> >>> 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. >>> >> >> >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
