#12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 ryantrinkle): simonpj: Yes. I've always encouraged the abstract style ( {{{ (MonadReader r m, MonadWriter w m) => m a }}} rather than {{{ ReaderT r (WriterT w m) a }}} ), so that the concrete monad transformer stack can be changed without modifying user code. It has worked really well to help keep code clean and organized (especially with GHC 8.0's warnings for unused constraints). So, in a typical reflex widget, there will be several constraints, e.g. DomBuilder t m, PerformEvent t m, PostBuild t m. Reflex is currently a superclass of all of these, since the 't' parameter is only meaningful for its Reflex instance. I haven't looked into whether it's possible to eliminate Reflex from all of these classes, but I'll certainly try to do that if it'll help with optimization. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12791#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler