#15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (removed) * related: #15760 => * milestone: => 8.6.2 Comment: You're right, I misspoke about #15760 fixing this issue. Forget I said anything about that. Your fix smells correct to me, and if there weren't any other extenuating circumstances, I'd endorse it as the one true solution. Unfortunately, there's a bit of a thorny issue in that this code no longer works on GHC 8.6, and I don't see a simple way to work around the issue at the moment. We need to backport //something// to fix this, but the question is //what//. Alas, changing the way we desugar infix types to use `InfixT` would constitute a breaking change in practice, so I'm reluctant to backport that. There is quite a bit of code in the wild which, for better or worse, assumes that `InfixT` only ever appears in user written code (i.e., `InfixT` never appears in desugared or reified TH ASTs). See [https://github.com/glguy/th- abstraction/blob/5123c6d054d0949cb444590269f13e5d44699ab2/src/Language/Haskell/TH/Datatype.hs#L1156-L1160 this function] from `th-abstraction` as one example. I'm not sure what exactly would happen if we started feeding that function `InfixT`s, but I imagine that something or another would change at runtime, which would be awful for a point release. Therefore, I'm inclined to adopt the patch in comment:4 as a crude (and ideally, temporary) fix for this issue in an 8.6 point release (hopefully 8.6.2), and work towards implementing your more robust solution for 8.8. Does that sound reasonable? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15815#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler