[GHC] #8510: Clear up what extensions are needed at a Template Haskell splice site

[GHC]

#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