#4430: Better support for resolving infix expressions in template haskell
---------------------------------+------------------------------------------
Reporter: reinerp | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Template Haskell | Version: 6.12.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonpj):
Very good point. GHC's own strategy is very like your second option. The
parser parses all infix applications as left-associative (I think) with no
priorities. Then the renamer re-associates everythign based on priorities.
All TH-generated code goes through the renamer so the existing operator-
precedence re-association code will do the job nicely. So this looks to
me like a more attractive route than expecting the quasi-quoter to do it,
which is in general very hard. (Hard because even knowing which operator
is meant by `(***)` pretty much means implementing a rename, dealing with
imports, shadowing, and whatever.)
The renamer is not re-associating TH expressions at the moment, because
when converting from TH syntax to `HsSyn` the conversion function adds
`HsPar` parens around every operator application, and the renamer respects
`HsPar` parens of course.
In short, I quite like your `UnresolveInfixE` solution. It's different to
GHC's design, which has
{{{
data LHsExpr id
= ...
| OpApp (LHsExpr id) -- left operand
(LHsExpr id) -- operator
Fixity -- Renamer adds fixity; bottom until then
(LHsExpr id) -- right operand
| HsPar (LHsExpr id)
...
}}}
plus the expectation that all `OpApp` are unresolved until after renaming,
except where guided by `HsPar`. But that's probably less appropraite for
TH.
I'd welcome more ideas.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4430#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
