#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 facundo.dominguez):
What does parseExp do?
In the case of the `java` quasiquoter: * it adds a finalizer which generates the java method to call, e.g. `Object fresh_name() { return 0.0; }` * it inserts at the quasiquote location some foreign calls to have the generated java method invoked, and the result marshaled to Haskell.
What if the type mentions in-scope type variables (existentially or lambda bound)?
In that case, the variables will likely show up in the type returned by `reify`. We don't care much about that case, as the user of inline-java would be asked to add enough of a type signature to provide as much information as necessary to infer a reasonable type in java. Also, if you want to explore it, there would be an alternative design where it is possible to avoid introducing the variable `__ghc_qq_<hash_loc>`. This would involve extending the `Quasi` monad with a method {{{ qTypeOfCurrentQuasiQuote :: m TH.Type }}} which must be invoked in a module finalizer and yields the type of the quasiquote, which would require some interaction with the typechecker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13608#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler