#11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:19 goldfire]:
With `:type`, though, we don't want to instantiate, because doing so might change specified variables to invisible ones. Or in cases like `forall a. (a ~ Int) => ...`, instantiating and then solving will actually get rid of a variable.
I'm not sure I agree. `:type` takes an ''expression'' and ''infers'' its most general type. Sometimes that expression is a bare function name, but not always. In contrast `:info` takes a name, and tells you about it, with its un- instantiated type. So in cases like `forall a. (a~Int) => Int -> a -> Int` I think it would be absolutely acceptable to get rid of the variable in `:type`. Moreover, you can't consistently ''prevent'' it happening. Why should `:type f` and `:type (f 3)` behave so differently (when `f` has the type given earlier in this para)? In short, I suspect that using `Note [Instantiate when inferring a type]` for `:type` would be a jolly good thing. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11376#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler