#7939: RHS of associated type not kind-checked ------------------------------------------+--------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Difficulty: Unknown Testcase: ghci/scripts/T7939 | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Comment(by goldfire): As I was looking at all of this, I wasn't sure what to do about type variables like `b` above. My decision to leave it to be polymorphic was mostly from a lack of a clearly-articulated reason why some variables are polymorphic and some aren't. However, I don't think Simon's "scope" rule really does it. Currently, variables are kind-polymorphic-by-default in the following places: * Class definitions * Datatype definitions without a full kind signature * Associated type declarations * Vanilla type synonyms Variables are defaulted to `*` in the following places: * Top-level family declarations * Datatype definitions with a full kind signature And, with the kind inference for closed type families that Simon and I discussed, we have a third case: * Type variables in closed type families are kind-polymorphic, but unconstrained type variables are defaulted to `*`. The "scope" rule doesn't quite describe this menagerie. Even excepting closed type families, the scope rule fails for datatype definitions. Type variables in a (GADT-style) datatype definition have no scope, but they get their constraints other ways. It's easy enough in the implementation to make the type variable `b` from above default to `*`, and that might be sensible, but it does make for a rather complicated rule to state. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7939#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler