accessing compilation parameters from template haskell

Ganesh Sittampalam ganesh at earth.li
Fri Sep 16 09:53:24 CEST 2011


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.

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 at haskell.org [mailto:glasgow-haskell-users-
> | bounces at 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 at haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
> 




More information about the Glasgow-haskell-users mailing list