#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):
Reiner, I think it's quite orthogonal to all the "new directions" stuff,
so do not wait for that. I think it'd be great if you could do it.
The first thing is to write down exactly what the proposal ''is''. What
can users expect? For example if they write
{{{
x <- [| a + b * c |]
}}}
can will the `TH.Exp` bound to `x` be correctly associated? (Answer:
yes.) What about this?
{{{
x <- return (UnresolvedInfixE ... UnresolvedInfixE ...)
}}}
Answer, obviously no.
Is any arbitrary tree of `UnresolvedInfixE` applications ok? Eg
{{{
UnresolvedInfixE
(UnresolvedInfixE e1 op1 e2)
op2
(UnresolveInfixE e3 op3 e4)
}}}
I think this should be OK, and should be correctly re-associated. But
GHC's renamer currently expects operators to show up left-associated
(because that's what the parser does). You'd need to look at the renamer
to check it would do the Right Thing for arbitrary trees of
`UnresolvedInfixE`.
What happens when there's an ordinary `InfixE` mixed in? (Answer: don't
reassociate.)
Are sections allowed for `UnresolvedInfixE`? In `InfixE` the arguments
are `(Maybe Exp)` to allow sections, but I think we don't what that here.
Anyway, you get the idea. You could use the Trac wiki to write out the
design, so that it's of longer-term utility than an ephemeral email. Then
send the proposal to the libraries list.
Meanwhile, you can get hacking; it won't be too hard. Thank you!
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4430#comment:3>
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
