#4430: Better support for resolving infix expressions in template haskell
---------------------------------+------------------------------------------
Reporter: reinerp | Owner: igloo
Type: feature request | Status: patch
Priority: normal | Milestone: 7.4.1
Component: Template Haskell | Version: 6.12.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonpj):
Looks good to me.
* I think the name "`UnresolvedInfixE`" is rather long and clunky. I'd
be inclined to say "`UInfixE`" and explain the terminology in the comment.
What do you think?
* I like the long comment in `TH.hs`, but I think it'd be better in
`TH/Syntax.hs` where the constructors are declared. Also could you use
the `Note [blah]` format described here
[http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle]?
* In that comment you say "This special handling for sections is the
exception to the previous point". I don't understand this comment. The
use of `InfixE` in sections is not reassociated, just like any other use
of `InfixE`. Seems fine to me!
* In `Convert.cvtOpAppP` could you add a comment explaining ''why'' the
chain must be re-associated. It's because GHC's renamer expects to see
operator applications in a particular form; better say what that is. Are
you sere that `cvtOpAppP` puts an arbitrary tree into a list form? I have
not looked very carefully but I'm not sure it does.
Thanks
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4430#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
