Well, since the mtl default is to not only disallow multiple states of
#15927: Weird interaction between fundeps and overlappable instances -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 15632 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:6 Darwin226]: the same type, but multiple states of ANY type, I wouldn't really call this non-scaleable. It's strictly more flexible than mtl. I'm not following: the approach you're using 'allows' multiple states of same type in the sense you can stack a `String` on top of a `String`. But it's useless: `getMyState` as written will only access one of them. Then being "flexible" in this way, is only going to lead to confusion. Monad Transformers used to do this stacking. (I'm talking over 10 years ago.) The `l` in `mtl` stands for library: in general many modules might import `mtl` and declare instances of `MonadTrans`. If `mtl` were still relying on overlapping instances, it would be impossible/difficult to co- ordinate the instances to each use a unique type; and any code in modules using the stack would risk the well-known issues of 'orphan instances'. Perhaps your intended usage has a different pattern, and you're prepared to do the co-ordination manually. But at least for a sanity check, validate when you add a type to the stack that it's unique. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15927#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler