[GHC] #12778: Expose variables bound in quotations to reify

[GHC]

#12778: Expose variables bound in quotations to reify
-------------------------------------+-------------------------------------
        Reporter:                    |                Owner:  (none)
  facundo.dominguez                  |
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:
       Component:  Template Haskell  |              Version:  8.0.1
      Resolution:                    |             Keywords:  template-
                                     |  haskell reify
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D3003
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by mboes):

 Replying to [comment:9 simonpj]:
 > That's helpful.  So you can do it today, [...] but that's a bit painful
 to write.

 That's right. And not something I'm keen to ask my users to have to write.
 #13608 proposes to make the exact style of your example (giving a name to
 quasiquote results) the default desugaring for all quasiquotes.

 The semantics I'd expect for `addModFinalizer` is:

 * Runs ''after'' all variables everywhere in the module have a type
 (including after TH expansion).
 * Like any `Q` action, the finalizer is allowed to perform I/O.
 * ''Any'' variable that is in context of the finalizer at the creation
 site can have its type reified.
 * The order of execution of each finalizer, if there are several, is
 undefined.

 This ticket proposes to extend the set of reifiable variables to include
 in addition:

 * variables in the scope of the `Q` action that created the finalizer.

 Not all of these will have types by the time the finalizer runs, because
 some variables might never be spliced in. But those that do, should have
 their type available in the finalizer.

 #13608 is a much more modest change in comparison.

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