#4430: Better support for resolving infix expressions in template haskell
---------------------------------+------------------------------------------
Reporter: reinerp | Owner: reinerp
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 reinerp):
That alone would not be sufficient. We would also need to add a
{{{Paren}}} data-constructor, in order to distinguish the following two
expressions:
{{{
[parseHaskell| (a * b + c) - d / e |]
[parseHaskell| a * b + c - d / e |]
}}}
(In the first, we want to reassociate within the brackets, and outside the
brackets, but not across the brackets.)
For completeness, we would also like to support unresolved ''sections'',
such as
{{{
[parseHaskell| (a * b *) |]
[parseHaskell| (* a * b) |]
}}}
If {{{*}}} is left infix, then only the first of these two is valid; if it
is right infix, then only the second of the two is valid.
So we might end up with
{{{
data Exp = ...
| UnresolvedInfixE
(Maybe Exp) -- Left
Exp -- Operator
(Maybe Exp) -- Right
| Paren Exp
}}}
with the understanding that any tree of adjacent {{{UnresolvedInfixE}}}
constructors is reassociated (but of course we don't reassociate across
parentheses). I could do that.
(My initial objection to this is simply that we're adding the {{{Paren}}}
constructor, whose only purpose is to signal "don't reassociate
{{{UnresolvedInfixE}}} trees across me" -- and then this leads me to try
and shove the entire tree-to-be-reassociated into one constructor -- say,
something like
{{{
data Exp = ...
| UnresolvedInfixE
[Exp] -- operators, in order
[Maybe Exp] -- operands, in order
}}}
I don't have a strong preference either way.)
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4430#comment:7>
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
