Problems with Template Haskell

[George Russell]

Simon Peyton-Jones wrote (snipped):

> Still, in your cpp-like application, I guess your story is that the
> condition might evaluate to True only if the system configuration was
> such that bar was in scope.  If the condition evaluates to False, then
> bar really might not be available.
> 
> OK, in TH (version 2 -- CVS HEAD) you want dynamic binding. You can say
> 
> 	$(if ... then [|d foo = $(dyn "bar") |] .. )
> 
> Now you won't get any type complaint, and "bar" will get looked up at
> the splice site of x. 

This is a bit cumbersome.  Could there be some way of wrapping the whole
quasi-quotation to stop it from being looked at in any way, except what
is strictly necessary for converting it to a Q Dec or Q Exp, unless and
until it is actually spliced?  In fact, I for one would prefer that to be
the default ...

I appreciate that there are workarounds like $(dyn ...), and I've also
come up with the solution of declaring

    idVar = [| id |]

and then using $idVar in quasi-quotations, as a way of obfuscating the
type so GHC doesn't complain.  This is what is known as fighting the compiler ...

> Does that help?

With "dyn" there's the problem that the module name and name of "dyn" have
changed from ghc6 to ghc6.3.  Meaning (a) without CPP I can't import
Language.Haskell.THSyntax (6.0) / Language.Haskell.TH (6.3); (b) I can't refer to
dyn in the first place anyway.  While with CPP it all seems so easy.

Of course (a) is an instance of a more general problem -- that we can't
use Template Haskell to select between import declarations.  It would be nice
if we could.

Of course there's the obvious problem that Template Haskell itself expects to
be able to use the variables in imported modules.  Would it be possible to allow
a splice in the import list, but restrict its environment to previously imported
modules?

Am I doing the wrong thing here?  Should I simply give up on the idea of
replacing cpp with Template Haskell?