[GHC] #13608: Expose the type of quasiquotes

GHC ghc-devs at haskell.org
Mon Apr 24 02:31:52 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:                    |
-------------------------------------+-------------------------------------
Description changed by facundo.dominguez:

@@ -16,3 +16,2 @@
- Examining the context in which the quasiquote is used would allow to build
- the later variant. However, GHC provides no way to grab the type that it
- expects of the quasiquote.
+ Examining the type that GHC expects of the quasiquote would allow to build
+ the later variant. However, GHC provides no access to it.
@@ -52,1 +51,1 @@
- to provide some feedback about the proposal meanwhile.
+ to provide some feedback meanwhile.

New description:

 It happens with inline-java that
 {{{
 [java| 0.0 |]
 }}}
 produces a static method in java
 {{{
 Object fresh_name() { return 0.0; }
 }}}
 where
 {{{
 double fresh_name() { return 0.0; }
 }}}
 would be preferred. This is better because the user would get an error if
 the expression does not match the expected result type.

 Examining the type that GHC expects of the quasiquote would allow to build
 the later variant. However, GHC provides no access to it.

 The quasiquote desugars as follows:
 {{{
   [java| 0.0 |]
 ====>
   $(parseExp java " 0.0 ")
 }}}

 We have experimented with a patch that desugars instead like
 {{{
   [java| 0.0 |]
 ====>
   let __ghc_qq_<loc_hash> = $(parseExp java " 0.0 ")
    in __ghc_qq_<loc_hash>
 }}}

 The quasiquoter can learn then of the expected type by doing:
 {{{
 do qqName <- getCurrentQuasiQuoteName
    addModFinalizer $ reify qqName >>= ...
  where
    getCurrentQuasiQuoteName :: Q Name
    getCurrentQuasiQuoteName = do
      loc <- TH.location
      return $ mkName $ "__ghc_qq_" ++ hash loc
 }}}
 Where `getCurrentQuasiQuoteName` can be provided in
 `Language.Haskell.TH.Quote`.

 This addresses the same concern that I initially intended to solve with
 the more complex proposal in #12778.

 I hope to submit a patch this week, but it would be useful if people want
 to provide some feedback meanwhile.

--

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


More information about the ghc-tickets mailing list