#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