[GHC] #10572: Type signatures are not implicitly quantified over TH type variables

[GHC]

#10572: Type signatures are not implicitly quantified over TH type variables
-------------------------------------+-------------------------------------
        Reporter:  spinda            |                Owner:  (none)
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:
       Component:  Template Haskell  |              Version:  7.10.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
                                     |  tests/th/T10572a, tests/th/T10572a
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4641
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by simonpj):

 * cc: goldfire (added)


Comment:

 Thanks for the patch.  I've had a look, and I really wonder whether the
 gain is worth the pain.

 The pain is significant: a whole extra usually-wasted pass `trySpliceTy`
 over every `HsType` to expand any splices, before renaming. And I'm not
 even certain that will work; what about
 {{{
 f :: $(g 'a) -> a
 }}}
 Here `g 'a` might expand to some type involving `a`; but it does require
 `a` to be in scope already.

 In the examples, wouldn't it all be clearer if we had an explicit forall?
 Thus
 {{{
 const'' :: forall a. [tv|a|] -> b -> [tv|a|]
 }}}
 Overall, I feel unsure about this.

 Richard, you are TH supremo, and you wrote the still-rather-cyptic note
 {{{
 Note [rnSplicePat]
 ~~~~~~~~~~~~~~~~~~
 Renaming a pattern splice is a bit tricky, because we need the variables
 bound in the pattern to be in scope in the RHS of the pattern. This scope
 management is effectively done by using continuation-passing style in
 RnPat, through the CpsRn monad. We don't wish to be in that monad here
 (it would create import cycles and generally conflict with renaming other
 splices), so we really want to return a (Pat RdrName) -- the result of
 running the splice -- which can then be further renamed in RnPat, in
 the CpsRn monad.

 The problem is that if we're renaming a splice within a bracket, we
 *don't* want to run the splice now. We really do just want to rename
 it to an HsSplice Name. Of course, then we can't know what variables
 are bound within the splice. So we accept any unbound variables and
 rename them again when the bracket is spliced in.  If a variable is
 brought
 into scope by a pattern splice all is fine.  If it is not then an error is
 reported.

 In any case, when we're done in rnSplicePat, we'll either have a
 Pat RdrName (the result of running a top-level splice) or a Pat Name
 (the renamed nested splice). Thus, the awkward return type of
 rnSplicePat.
 }}}
 (NB: the pattern situation is much less bad than the propose solution for
 types, because it doesn't require a whole extra pass.)

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10572#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler