Nested QuasiQuote Support #9

gbaz opened this Issue Oct 13, 2011 · 6 comments


None yet

4 participants

gbaz commented Oct 13, 2011

Currently, while haskell-src-exts supports quasiquotes, haskell-src-meta doesn't implement a translation for them. We can't straightforwardly implement quasiquote expansion as a prepass, because that means running them as a function of String -> HS.Exp, when quasiquoters are of type String -> TH.ExpQ. So on the one hand, we could write a TH -> HS converter (and thus roundtrip quasiquotes an extra time), or we could parameterize ToExp & friends over a dictionary, which includes a map of strings to quasiquoters at the least (and perhaps a few other things?). Alternately, rather than parameterizing directly over a dictionary of quasiquoters, we could add a more general "open recursion" style scheme where functions of type HS -> Maybe TH are passed around and tried first, and only failing their success are the standard cases tried.

Sorry if this is a bit dense -- I hope it explains the issues involved well enough.


This sounds like a lot of work and complication for a feature most people won't use. I'm not willing to write the code for it, and I'll probably only accept patches if I'm convinced people would actually use the feature.


(although if you want to send a patch and then help maintain the package, you're welcome to :P )

ddssff commented Aug 26, 2013

I need this feature, and I'm willing to write code for it. I just need a little guidance about what the SpliceExp case in Translate.hs would look like. It seemed to me that it would be necessary to change the signature of ToExp to return ExpQ instead of Exp, so I did that. It also led to similar changes for ToType, ToPat, ToDec, ToDecs, and ToStmt. What I don't know is how to get at the template haskell bindings when I see an IdSplice. If anyone can educate me I would be grateful.


We can't get rid of HSE.Exp -> TH.Exp entirely (ExpQ can't be turned into Exp in general).

I can't help you much, to be honest. It's precisely that I don't know the right way of doing this that has stopped me from trying already :)

@aavogt aavogt added a commit to aavogt/haskell-src-meta that referenced this issue May 22, 2014
@aavogt aavogt preliminary implementation for #9 as a prepass 8c66797
@aavogt aavogt added a commit to aavogt/haskell-src-meta that referenced this issue May 22, 2014
@aavogt aavogt preliminary implementation for #9 as a prepass 34b88d0
Wizek commented Sep 16, 2016

This question interests me too.
Is the problem the type of parseExp :: String -> Either String Exp?
And if so, couldn't we have an additional function of type parseExpQ :: String -> Either String (Q Exp)?

Wizek commented Sep 16, 2016

I'd also like to provide a use-case as a response to "a feature most people won't use":

I have begun to write a simple assertion QuasiQuoter that I use to provide me with more information at a glance about which tests have failed, while allowing me to having to write less descriptions by hand:


[aa| ("aI b = 1" $> parseLineToDepsG $> f) `shouldBe` ("a", ["b"]) |]
[aa| ("aI b = \\ x -> 1" $> parseLineToDepsG $> f) `shouldBe` ("a", ["b"]) |]
[aa| ("aI = 1 > 1" $> parseLineToDepsG $> f) `shouldBe` ("a", []) |]


Which when executed with hspec looks like this:

And I'd like to begin to support quasiquotes and splices inside too, like:

[aa| ([text|
    = 1
|\] $> T.unpack $> parseLineToDepsG $> f) `shouldBe` ("a", ["b"]) |]

Do you think this could be possible?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment