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](http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal)
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
For context, the Hackage package [haskell-src-meta](http://hackage.haskell.org/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.
<details><summary>Trac metadata</summary>
| 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 | |
</details>
<!-- {"blocked_by":[],"summary":"Better support for resolving infix expressions in template haskell","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Consider writing a quasiquoter to parse haskell (for example, the {{{parseHaskell}}} quasiquoter mentioned in Part D of [http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal Simon's TH blog post]\r\n\r\nHow is the quasiquoter supposed to handle infix expressions, such as\r\n\r\n{{{\r\nfoo = [parseHaskell| 3 * 5 + 4 |]\r\n}}}\r\n\r\nIn 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\r\n\r\nFor context, the Hackage package [http://hackage.haskell.org/package/haskell-src-meta 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.\r\n\r\nOne 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. \r\n\r\nA 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:\r\n\r\n\r\n{{{\r\n...\r\n | UnresolvedInfixE [(Exp, Exp)] Exp\r\n...\r\n}}}\r\n\r\nwith 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.","type_of_failure":"OtherFailure","blocking":[]} -->
issue