#15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies 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): The covars are always empty. That comment is right. Along the way to `-XTypeInType`, there were some scenarios where the covars weren't empty. Mutterings to self are memorialized [https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Matchingaxio... here]. As for pretty-printing behavior, I have a few observations: - The AST indeed stores whether or not the user wrote a `forall`, because some of the warnings, etc., are different based on this choice. However, once a type family equation is accepted, the presence/absence of the `forall` is immaterial. - The order of variables in the `forall` is immaterial to users. Not sure if this is a problem at all, but there's never a way to manually instantiate the variables, so we don't have to care about order. - Visibility/specificity is simply not a thing for the variables bound in a type family equation, also because the user can't ever instantiate these manually. - The funny `[a]` syntax was invented because using `forall` here is a tiny bit of a lie: `forall` is a specific construct in Core that does not exist in type family equations (i.e. coercion axioms). I don't think this is useful or friendly to users, though. Do these design points help? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15827#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler