I still say that most uses of `mkNthCo` already know the right role --
#11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:29 goldfire]: though perhaps this role may not be as obvious to someone who isn't me. Just supplying the role would be much better than computing it, of course. It is indeed a bit less obvious to me; I have found a few places (2 or 3 I think) where we have a role ready that could be a candidate, but not being sure whether it would be the right thing, I opted for the conservative option.
I don't agree with Simon's suggestion about `mkNthCoDirect` -- this is a first step toward invariants that are not upheld. Instead, I would have `mkNthCo` require a role and make a new `mkNthCoNoRole` that computes it. The naming of the functions should discourage the use of the second.
The Note explaining why I originally bundled `coercionKind` and `coercionRole` points to a test case. Does that give a concrete testing ground? You might also look in the git history around that note to see if
I have absolutely no opinion on this one; happy to implement it either way. that gives you any pointers. OK, will take a look.
Agreed about not cluttering `IfaceCoercion`.
Yes, makes total sense. Undoing as we speak. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11735#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler