Why doesn't TH expose its parser?
What's the reason that there isn't a parseExp :: String -> Q Exp, parseDecl, etc.? It's a pretty common use case to write some syntactic extension that merely extends regular Haskell. We end up with the haskell-src-meta package which doesn't support full GHC Haskell and doesn't know how to parse infix applications. It doesn't give a strong story for quasi-quotes to be useful for extensions to Haskell's syntax itself, as opposed to just mini-DSLs. Here's a case in point: idiom brackets. You'd like to implement them like this: [i|foo bar mu|] → foo <$> bar <*> mu You want it to be full Haskell inside, so foo could easilly be a case or a let, etc., so a trivial way to do that would be to just parse the string "foo bar mu" with parseExp and then do the above simple transformation. Job done. In practice, we can't do this. Our best option is HSE, but it's not ideal. Another way to do this is: $(idiom [|foo bar mu|]) And because [|…|] produces a Q Exp, you can just go ahead and do the rewrite on the resulting Exp. Yay, we now have full GHC Haskell inside the idiom bracket, but we've lost the syntactic convenience. Given that [|…|] already does the String → Q Exp step, why not allow us to re-use this functionality in quasi quotes? Ciao!
| What's the reason that there isn't a parseExp :: String -> Q Exp, | parseDecl, etc.? Good idea! I don't think it'd be too hard. The parser (in parser/Parser.y) already exposes parseExpression, parseDeclaration etc. But they generate HsSyn and we need TH syntax. We don’t currently have a way to do that. It's (B) in https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Conversions So there's some refactoring work to do here. Fiddly but not hard. Simon | -----Original Message----- | From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Christopher Done | Sent: 13 February 2015 21:32 | To: Haskell Cafe | Subject: [Haskell-cafe] Why doesn't TH expose its parser? | | What's the reason that there isn't a parseExp :: String -> Q Exp, | parseDecl, etc.? | | It's a pretty common use case to write some syntactic extension that | merely extends regular Haskell. We end up with the haskell-src-meta | package which doesn't support full GHC Haskell and doesn't know how to | parse infix applications. It doesn't give a strong story for | quasi-quotes to be useful for extensions to Haskell's syntax itself, | as opposed to just mini-DSLs. | | Here's a case in point: idiom brackets. You'd like to implement them like | this: | | [i|foo bar mu|] → foo <$> bar <*> mu | | You want it to be full Haskell inside, so foo could easilly be a case | or a let, etc., so a trivial way to do that would be to just parse the | string "foo bar mu" with parseExp and then do the above simple | transformation. Job done. | | In practice, we can't do this. Our best option is HSE, but it's not | ideal. Another way to do this is: | | $(idiom [|foo bar mu|]) | | And because [|…|] produces a Q Exp, you can just go ahead and do the | rewrite on the resulting Exp. Yay, we now have full GHC Haskell inside | the idiom bracket, but we've lost the syntactic convenience. Given | that [|…|] already does the String → Q Exp step, why not allow us to | re-use this functionality in quasi quotes? | | Ciao! | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe
On 13 February 2015 at 23:36, Simon Peyton Jones
| What's the reason that there isn't a parseExp :: String -> Q Exp, | parseDecl, etc.?
Good idea! I don't think it'd be too hard. The parser (in parser/Parser.y) already exposes parseExpression, parseDeclaration etc. But they generate HsSyn and we need TH syntax. We don’t currently have a way to do that. It's (B) in https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Conversions
So there's some refactoring work to do here. Fiddly but not hard.
Awesome! I wasn't sure whether I wasn't taking into account a subtle stage restriction problem somehow. Nice diagram. :-) I'm looking at the TH implementation to see whether this is something I can reasonably tackle. Cheers!
It appears my information is out of date on at least haskell-src-meta and would be misleading to others if I didn't correct it: since GHC 7.4 haskell-src-meta can now leave infix applications ambiguous and allow GHC to resolve them: http://hackage.haskell.org/package/haskell-src-meta-0.6.0.8/docs/Language-Ha... The problem of dealing with infix applications remains in your quasi quoter remains, of course. But that's a handy improvement.
participants (2)
-
Christopher Done -
Simon Peyton Jones