#11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1744 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): I finally had a moment to take a closer look at the code and I have some concerns. Most importantly, I don't understand how we can actually have infix GADT constructors. Splicing creates an `HsDecl.ConDecl` data type, which can be either `ConDeclGADT` or `ConDeclH98`. The latter constructor has field `con_details :: HsConDeclDetails name`, where `HsConDeclDetails` is a type synonym to: {{{#!hs data HsConDetails arg rec = PrefixCon [arg] -- C p1 p2 p3 | RecCon rec -- C { x = p1, y = p2 } | InfixCon arg arg -- p1 `C` p2 }}} There is no such field in `ConDeclGADT` data constructor, so how can we mark a constructor declaration as infix? You're asking:
what happens when you try to splice an infix `GadtC` into source code in `Convert.hs`?
Indeed, what should happen in such a situation? I believe we should splice a normal GADT constructor because we have no way of expressing the infixity. Ryan, you also said in an earlier comment:
A GADT constructor is only considered to be declared infix if (a) it is an operator symbol, (b) it has two arguments, (c) it has a fixity declaration.
Can you show me where this happens in code? Your ticket reports actual problems in the implementation but I am not sure that the way you trying to address them is correct. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11345#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler