[GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications

[GHC]

#11376: Inconsistent specified type variables among functions and datatypes/classes
when using -XTypeApplications
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  goldfire
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.0.1
       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 goldfire):

 After more thought, I think this is a move in the wrong direction. The
 evidence I use to make my case is
 [https://phabricator.haskell.org/rGHCf2a2b79fa8d1c702b17e195a70734b06625e0153#da6fd6c4
 this change]. Because of the change proposed (and implemented) here, GHC
 effectively erases information about specified vs. inferred variables
 before printing a type. One could argue that this information is
 recoverable with `:info`, but this is not easily true for data
 constructors, which print out their definition with `:info`, not their
 type. And, personally, when I want the type of a function, I just say
 `:type`, not `:info`, even when that expression is just a bare function.

 If (1) from comment:21 is considered abhorrent (and I admit it's
 unsavory), then I think we should strive for (2). Here is an attempt at a
 specification & implementation for (2):
 In `:type`, we do no type instantation, but we ''do'' try to solve
 constraints, by looking for any constraints in the type (even nested to
 the right of arrows), plucking them out of the type, and trying to solve
 them (by emitted wanteds and running the solver directly from `tcRnExpr`).
 Any unsolved constraints are then put back in the type, being careful to
 keep things well-scoped.

 Even after writing that, I don't like it at all. But with the patch as
 written, we're actively throwing away information that's hard to come by
 otherwise.

 == A new, crazy idea ==

 Currently, GHCi stores the result of an evaluation in `it`. I propose
 storing the type of an evaluation (or call to `:type`) in `It` (so that
 `it :: It`). And then a new directive `:simplify` takes a type and
 simplifies it as much as possible, much like `simpliferInfer` does. So a
 user could say `:t length @[]`, get something with an unsolved `Foldable`
 constraint, and then just say `:simp It` and get what they want.

 We could even have `:type` try to simplify and report both types if they
 are different.

 I'm not suggesting this for 8.0, but I think it's a better plan than this
 patch, which I advocate reverting.

 Note: my comment:23 admission was thinking about the large mass of users
 that don't know about visible type application. But only those use visible
 type application will be bitten by the strange behavior! So I take back
 comment:23.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11376#comment:29>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler