#11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): There is something odd happening here. '''I do not expect the in-scope set to be evaluated at all (that is, it should remain as a thunk) when substituting into for-all-free types'''. That was why I thought it worth writing `piResultTys` (plural). Consider `piResultTys (forall a b. blah) [t1, t2]`. If we substitute one `[a->t1]`, and then `[b->t2]` the first will substitute into `forall b. blah` and that will force the in-scope set. But if we do both at once, we won't, provided `blah` has no foralls, which is the wildly common case. So how can it possibly cost 10% of all of compile time in this single tiny function???? That is utterly bizarre. Are you sure ASSERTs are off? They do a lot of forcing! Maybe you can just `pprTrace` what is going on, to see if the in-scope sets are being unexpectedly forced. If so, fixing that might fix a LOT of things. Yes, it might be good to give the in-scope set to `piResultTy(s)` when it's available, but please, before you do that, can you get more insight into what is happening? Thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11371#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler