| Would making a template-haskell-ghc package make sense? Might be | overkill just for my requirement but there could be other things like | support for GHC-specific language extensions that might also logically | belong there. I don't know -- I don't know what it would look like. By all means have a go! S | | On 16/09/2011 08:21, Simon Peyton-Jones wrote: | > The difficulty here is that the TH library, by design, doesn't depend on GHC. So | we can't have a TH function | > getFlags :: Q DynFlags | > or (as you suggest, more or less) | > runTc :: TcM a -> Q a | > because to write those type signatures in Language.Haskell.TH.Syntax you'd need to | import GHC. | > | > There's no difficulty in *practice*! Q more or less *is* TcM. | > | > Still I don't really know how to get around this in a beautiful way. | > | > Simon | > | > | -----Original Message----- | > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | > | bounces@haskell.org] On Behalf Of Ganesh Sittampalam | > | Sent: 16 September 2011 06:42 | > | To: GHC users | > | Subject: accessing compilation parameters from template haskell | > | | > | Hi, | > | | > | It would be useful to access the current compilation parameters or even | > | an entire RunGhc monad from inside a Template Haskell splice. Is there | > | any way to do this? | > | | > | The reason I want to do this is I'm using the ghc API at runtime to | > | dynamically execute code, and I want both the dynamically loaded code | > | and static code to use a shared runtime module that defines some types | > | used for communication across the boundary. To guarantee the internal | > | representations etc are the same, I store the object file of the runtime | > | during compilation then load it dynamically at runtime - but to make | > | this work I need to know where the object file is (-odir and -hidir) and | > | I also need to know or be able to deduce the GHC DynFlags so I can | > | replicate them at runtime. | > | | > | I could also achieve this goal by putting my runtime in a separate | > | package and installing it first, but that's less self-contained and | > | would be a pain during development. | > | | > | Cheers, | > | | > | Ganesh | > | | > | _______________________________________________ | > | Glasgow-haskell-users mailing list | > | Glasgow-haskell-users@haskell.org | > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users