-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nested QuasiQuote Support #9
Comments
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 ) |
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 :) |
This question interests me too. |
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: Example: [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", []) |] Source: https://github.com/Wizek/hs-di/blob/8cff246/test/MainSpec.hs#L258 Which when executed with hspec looks like this: And I'd like to begin to support quasiquotes and splices inside too, like: [aa| ([text|
aI
b
= 1
|\] $> T.unpack $> parseLineToDepsG $> f) `shouldBe` ("a", ["b"]) |] Do you think this could be possible? |
I just hit a use case for this. I'm using quasiquotes to provide a nicer literal syntax for a length-indexed list, so I use haskell-src-meta to easily support any haskell expression for the items of the list. But then I needed a "sum-indexed list" (an unknown number of Nat-indexed items whose indexes sum up to a statically known value), so I followed the same pattern and made a quasiquote for that too. But some of the key things you'd want to put in the sum-indexed list are length-indexed lists. It's not a complete loss, as I can still use the constructors directly, or bind the individual lists to variables ahead of time. But the failure is a bit jarring. |
Am I right in thinking that the essential problem is that there's no template haskell representation of template haskell syntax (like quasiquotes), so to produce a |
Yes, that is the essential problem. |
IMO this is outside the scope of haskell-src-meta (it would require more than just a translation). However if the code only needs to support a given set of quasi-quoters, it could perhaps be done by preprocessing. A function something like this: |
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.
The text was updated successfully, but these errors were encountered: