[GHC] #15952: Reduce zonking-related invariants in the type checker

[GHC]

#15952: Reduce zonking-related invariants in the type checker
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:  (none)
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:  8.6.3
       Component:  Compiler          |              Version:  8.6.2
      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 goldfire):

 I agree we may not need `substTy` to be monadic. But if we don't make it
 monadic, it should panic if it ever spots a `TcTyVar`.

 The problem with making `typeKind` respect the `Type`/`Constraint`
 distinction is that it means everyone pays the price. Specifically,
 `typeKind (FunTy {}) = liftedTypeKind` is just fine right now, but if we
 want to get `typeKind` correct w.r.t. `Constraint`, then this case will
 have to recur (because of quantified constraints). I agree that doing this
 wouldn't cause misbehavior, but it would potentially slow, e.g., core
 passes down.

 > We probably want to keep the pure version for occasions where we know
 the types are zonked.

 True, but only for syntactic convenience, right? The monadic version
 should be no less efficient than the pure one, if there are no metavars, I
 would think.

 I agree about the idea about the visibility stuff. It might be worthwhile,
 for performance reasons, to make the decision about visibility once, at
 the top of `tcEqType`, and then have two mostly-identical recursive
 functions, one which accounts for visibility and one that doesn't. The
 alternative is to consult the flag many times during the recursive
 processing, which seems wasteful.

 If `tc_eq_type` really is only ever called with `tcView`, then yes,
 specialize.

 Does that get you unblocked?

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