#3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.10.1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T3064 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): It may be "a little disappointing" but nevertheless I think it's a notable step forward: * It eliminates a tricky and hard-to-explain complication in the implementation. * It fixes a substantial performance regression that affects programs with deeply-nested superclasses, affecting both compile time and run time. * It eliminates a collection of regressions, whereby silent superclasses actually cause some programs to fail unexpectedly, for very hard-to- explain reasons. They are listed in the commit message. * Moreover, there is no good workaround if you actually hit those regressions. In contrast, there is an immediate and easy workaround if you hit the new regression. * None of this bites you unless you are sailing close to the wind (`UndecidableInstances`). As to whether this belongs in 7.10 I am agnostic. The performance improvements will help everyone slightly (especially in monad-transformer- heavy code). The behaviour change is there all right, but will affect very few people. I don't feel strongly either way. I am not arguing to push it into 7.10, but I will not argue against doing so either. Does anyone else have a view? The default decision is "no" because it is a change wrt RC1. Incidentally, you say "in perverse but realistic scenarios, might cause the superclass dictionary to loop". Indeed it is realistic. It would be all too easy to add by accident {{{ instance (UserOfRegs r CmmExpr) => UserOfRegs r CmmReg where ... }}} perhaps even in another module. Guarding against such subtle loops is a very good thing, in my view. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3064#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler