#13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is a change to the source language, so you should really make a [https://github.com/ghc-proposals/ghc-proposals GHC propsal] for it. That way you would get good feedback. Is the current TH finaliser design (with the recent modificadtions you put in) written up anywhere? If not, it would be good to do that at the same time. I Utterly Hate the idea of making up a funny name based on the hash of a location, and then having to guess what it is (inside your function `getCurrentQuasiQuoteName`). Yurgh. Could you not arrange that your Java parser, instead of producing some Haskell expression `e`, produced the Haskell expression `let my_name = e in my_name`, where `my_name` is a TH name that you generate. Now you know what it is! But now you'll tell me that it's not in scope in the typechecker's environment when it encounters the quasi-quotes... but then quasi-quotes run in the renamer anyway. I'm very lost as you can see, but the current design just smells wrong to me. There are lots of clever people around GHC. Perhaps if you explain the original problem, and your current solution, someone may have a good idea. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13608#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler