We probably want to keep the pure version for occasions where we know
#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. 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