#15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): My guess is that it is a pretty-printing bug, as if it were anything more serious would have been discovered by now. I would start by looking at `Coercion.pprCoAxiom`. Actually, better than just fixing this bug would be removing `Coercion.pprCoAxiom` in favor of the `IfaceAxiom` case of `pprIfaceDecl`. Unless it's not a pretty-printing bug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15852#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): `IfaceTyConInfo` or `IfaceTyConSort` might be possible candidates for storing this information. Currently, these are defined as: {{{#!hs data IfaceTyConInfo -- Used to guide pretty-printing -- and to disambiguate D from 'D (they share a name) = IfaceTyConInfo { ifaceTyConIsPromoted :: IsPromoted , ifaceTyConSort :: IfaceTyConSort } -- | The various types of TyCons which have special, built-in syntax. data IfaceTyConSort = IfaceNormalTyCon -- ^ a regular tycon | IfaceTupleTyCon !Arity !TupleSort -- ^ e.g. @(a, b, c)@ or @(#a, b, c#)@. | IfaceSumTyCon !Arity -- ^ e.g. @(a | b | c)@ | IfaceEqualityTyCon -- ^ A heterogeneous equality TyCon }}} (The Haddocks for `IfaceTyConSort` are misleading, since //every// `IfaceTyCon` has one, not just those with special, built-in syntax. Regardless of how we fix this bug, we should change that documentation to reflect reality.) My vote would be to extend one of these data types with an extra field of type `IfaceTyConParent`, which would be sufficient to tell if a `TyCon` came from a data family instance or not. Then it would just be a matter of plumbing this information to `pprAxBranch` from its call sites. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15852#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Oh dear. Yes, I //was// barking up the wrong tree—thank you for setting me straight. Now that I dig closer into `ppr_co_axiom_branch` (which is the real culprit), I now understand what went wrong. When implementing `etaExpandFamInstLHS`, I left [http://git.haskell.org/ghc.git/blob/d30352add1da67dd0346613853cd423c7becbaeb... this comment]: {{{#!hs -- @Note [Eta reduction for data families]@ in "FamInstEnv". Because the -- right-hand side is where the eta-reduced variables are obtained from, it -- is not returned from this function (as there is never a need to modify it). }}} In retrospect, I have no idea what I was smoking when I wrote this comment, because it's completely wrong. The right-hand side //is// eta- reduced, and that's what we're seeing in `-ddump-tc`. (Moreover, we aren't obtaining the eta-reduced variables from the RHS at all. They're actually being taken from the `tyConTyVars` of the representation `TyCon`.) This suggests a straightforward fix: just eta expand the RHS as well, and return that from `etaExpandFamInstLHS` (or really, it just should be called `etaExpandFamInst`). I'll give that a shot. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15852#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5328 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"014d6c1f08808c4dab6cba80efdc634527d91086/ghc" 014d6c1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="014d6c1f08808c4dab6cba80efdc634527d91086" Fix #15852 by eta expanding data family instance RHSes, too When I defined `etaExpandFamInstLHS`, I blatantly forgot to eta expand the RHSes of data family instances. (Actually, I claimed that they didn't //need// to be eta expanded. I'm not sure what I was thinking.) This fixes the issue by changing `etaExpandFamInstLHS` to `etaExpandFamInst` and, well, making it actually eta expand the RHS. Test Plan: make test TEST=T15852 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15852 Differential Revision: https://phabricator.haskell.org/D5328 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15852#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler