[GHC] #13608: Expose the type of quasiquotes

GHC ghc-devs at haskell.org
Tue Jun 6 12:19:17 UTC 2017


#13608: Expose the type of quasiquotes
-------------------------------------+-------------------------------------
        Reporter:                    |                Owner:
  facundo.dominguez                  |  facundo.dominguez
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:
       Component:  Template Haskell  |              Version:  8.0.1
      Resolution:                    |             Keywords:  QuasiQuotes
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  12778             |  Differential Rev(s):  Phab:D3610
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 > I don't submit a GHC proposal because we don't have yet a good solution
 to propose

 Indeed.  And I don't feel comfortable about any of the solutions you
 propose, because they all feel so specific and ad-hoc.

 Is there anything we could do to have a more basic mechanism that is also
 more flexible?  It seems that, for a given top-level splice (or
 quasiquote), you want to have the opportunity to do some arbitrary work
 "later", when type checking is complete; a bit like a core-to-core pass
 that works through those splices.

 Suppose you could say
 {{{
 addPostProcessor :: (CoreExpr -> IO (CoreExpr, [CoreBind])) -> Q ()
 }}}
 So `addPostProcessor f` would say

 * When type checking and desugaring is complete, please run `f` on the
 spliced-in expression.
 * `f e` will return a new expression (of the same type) to replace it with
 (often just `e`).
 * ...and perhaps some new top-level bindings.

 The nice thing about this is that when we are in Core every `Id` has its
 type "inside" it; we don't need to consult any type environment etc, which
 has given us a lot of trouble with the `addModFinaliser` stuff (which this
 would replace).

 Just thinking aloud.  I don't want us to get stuck in a deeper and deeper
 pile of sticking plasters.

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


More information about the ghc-tickets mailing list