#15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: 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 simonpj):
What does it mean for a type variable to be a type variable?
Imagine the fully-typechecked Core program. Now, does the source-level type variable name a type variable, or some other non-type-variable type? Example: {{{ data T a = MkT a f1 :: T b -> Int f1 (MkT (x::z)) = ... -- OK f2 :: T Boll -> Int f2 (MkT (x::z)) = ... -- Not OK }}} In `f1` the source-level lexical type variable `z` names a type variable in Core. The elaborated version of `f1` could be {{{ f1 = /\b. \(x::T b). case x of { MkT (x::b) -> ... } }}} So `z` names `b`. In `f2`, you'll see that `z` names `Int`. I agree this is a questionable choice. At the time I was worried that it'd be confusing to have a type variable that was just an alias for `Int`; that is not a type variable at all. But in these days of GADTs and type equalities we are all used to that. We'd make a different choice today. Feel free to make a GHC proposal to change this behaviour. It'd be backward compatible! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15050#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler