[GHC] #13608: Expose the type of quasiquotes
GHC
ghc-devs at haskell.org
Mon Apr 24 11:43:50 UTC 2017
#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
More information about the ghc-tickets
mailing list