[GHC] #15298: Support spliced function names in type signatures in TH declaration quotes

[GHC]

#15298: Support spliced function names in type signatures in TH declaration quotes
-------------------------------------+-------------------------------------
        Reporter:  ntc2              |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Compiler          |              Version:  8.4.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #6089             |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 I don't think this would be too hard to fix.

 What you want is the ability to splice into a ''binding'' position, a
 place where a `Name` occurs.  We already have the ability to splice into a
 ''pattern'', and indeed you can say
 {{{
 fDecl1 :: DecsQ
 fDecl1 = [d| $(varP fName) = $fBody |]
 }}}
 where we are splicing a pattern on the LHS of a declaration `<pat> =
 <expr>`.  But that won't work for type signatures where you want a `Name`.

 If we had
 {{{
 fName :: Q Name
 fName = ...
 }}}
 then we jolly well ought to be able to splice it in in place of a name,
 even in (say) data type declarations
 {{{
 fDecl1 :: DecsQ
 fDecl1 = [d| data $fName = A | B |]
 }}}
 Nothing truly tricky there.

 But it'd be some work to implement:

 * A number of places in `HsSyn` that currently have a `Name`, or more
 precisely `(IdP pass)`, would need an extra constructor for a splice.
 Specifically:
   * The `tcdLName` field of a `TyClDecl`
   * The `fun_id` field of a `HsBindLR`
   * The second field of a `TypeSig` in the `Sig` type -- and perhaps other
 constructors too.

 * The renamer would have to run those splices.

 * We can't do dependency analysis until we'd run those splices, because we
 don't know what's being bound. (That is already the case with pattern
 bindings that have a splice.)  But maybe that doesn't matter, because the
 renamer will run those splices, maybe the dependency analysis occurs after
 that. I'm not quite sure.

 Any volunteers?

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