#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