#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 reinerp):
Thanks for reviewing.
* Sure, I'll change the name.
* I'll move the comment to TH/Syntax.hs. I'll adopt the style you linked
to, but I'll leave the {{{$infix #infix#}}} in, because that inserts the
note into Haddock and allows for hyperlinks as appropriate.
* I agree it's not reassociated, but there is some form of special
handling. Here's the problem. In Haskell, we have:
{{{
infixl +
(1 + 2 +) -- valid, and parses as ((1 + 2) +)
(+ 1 + 2) -- invalid
(+ (1 + 2)) -- valid
}}}
We need some way in Template Haskell to distinguish between the second
and third cases. With my patch, we get the following:
{{{
InfixE Nothing plus (UInfixE 1 plus 2) -----> (+ 1 + 2)
InfixE Nothing plus (Parens $ UInfixE 1 plus 2) -----> (+ (1 + 2))
}}}
So the {{{InfixE}}} is not reassociated, but whether it causes an error
depends on the {{{UInfixE}}} inside it (and in {{{Convert.cvtl}}} we see
fully-applied {{{InfixE}}} constructors put parentheses around their
arguments, whereas {{{InfixE}}} sections don't). So it's somewhat against
the spirit of "GHC won't play any tricks when you have an {{{InfixE}}}",
and should be documented somehow, even if it's not an exception.
* Yes, I was wondering about how much I should document. I could add a
brief comment explaining how {{{cvtOpAppP}}} works, along the following
lines.
{{{
We can see that @cvtOpAppP@ is correct as follows. The inductive
hypothesis
is that @cvtOpAppP x op y@ is left-biased, provided @x@ is. It is clear
that
this holds for both branches (of @cvtOpAppP@), provided we assume it
holds for
the recursive calls to @cvtOpAppP@.
}}}
I originally had a simpler (more obviously correct) implementation, but
in the worst case (starting with a completely right-biased tree) it had
quadratic complexity in the size of the input tree, whereas the current
implementation is linear.
Cheers,
Reiner
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4430#comment:15>
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
