#8510: Clear up what extensions are needed at a Template Haskell splice site -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): While I agree that the current situation -- anarchic is a good description -- should be improved, there are competing forces at work here. As Simon notes, it's possible to create syntax trees in TH without using TH quotes, which gets around the need for language extensions. Indeed, I tend to prefer writing my code this way, as the quoting mechanism isn't quite flexible enough for my needs. So, if we follow Simon's plan of requiring extensions only at the quote site, not at at the splice site, it's possible to write a program using arbitrary extensions while mentioning only `TemplateHaskell`. This seems to fly in the face of the desire to use extensions to help control which compiler (or which version of a compiler) is used to build a cabal package. On the other hand, requiring users of a TH library to turn on extensions feels silly. I know that this a (quite small) point of annoyance when I'm working on my `singletons` package. It currently requires users to turn on roughly 10 extensions to use it. Even worse, if a user doesn't turn on `ScopedTypeVariables` in particular, the error message is ''very'' obscure. One potential solution here is to allow TH to interact directly with the extensions mechanism. At the least, it could query what extensions are in force and then report errors or warnings to the user accordingly. At the most, TH would be able to turn on (and off?) extensions within splices. If the extensions are named via an enumeration type (as opposed to strings), that might be a poor man's mechanism to enforce that the compiler supports an extension -- if the extension isn't present, the use of the relevant constructor wouldn't compile. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8510#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler