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?
_______________________________________________ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
