Better support for resolving infix expressions in template haskell
Consider writing a quasiquoter to parse haskell (for example, the parseHaskell quasiquoter mentioned in Part D of Simon's TH blog post
How is the quasiquoter supposed to handle infix expressions, such as
foo = [parseHaskell| 3 * 5 + 4 |]In order to parse this expression properly, the quasiquoter needs to know the fixities of the operators mentioned, and this information is only available at the call site. We could try to use reify, but according to the description of "what reify sees" in the above-linked blog post, this would fail if, for example if the fixity is defined later in the file than the splice is done. Another obstacle to the reify approach is #4429 (closed)
For context, the Hackage package haskell-src-meta provides a haskell parser which produces TH, similar to the parseHaskell quasiquoter discussed above. This package does not, in general, parse infix expressions correctly.
One option for supporting fixities better is to improve reify. In particular, reify could be made to return an operator's fixity even if typechecking hasn't been performed.
A second option would be to move responsibility of fixity parsing away from the quasiquoter and back to GHC, by adding the following constructor (or similar) to template haskell's Exp datatype:
...
| UnresolvedInfixE [(Exp, Exp)] Exp
...with the intention that UnresolvedInfixE [("a","+"), ("b", "*")] "c" (here I take strings to be expressions) denote the (unparenthesised) expression a + b * c with the expectation that GHC will apply the correct fixities when splicing.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 6.12.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |