Помимо обратной совместимости, есть некоторые (в основном косметические, но утомительные проблемы) из-за довольно простого способа, которым Haskell обрабатывает классы типов:
Нет неявного восходящего определения : Monad полностью определяется просто pure и (>>=); fmap и (<*>) можно записать в терминах тех. В «правильной» иерархии каждый экземпляр должен быть записан. В этом случае это не так уж плохо, но с увеличением степени детализации увеличивается количество экземпляров, каждый из которых добавляет небольшую функцию. Это значительно упростило бы ситуацию, если бы определения классов могли предоставлять реализации по умолчанию для функций суперкласса в терминах их собственных функций, так что такие функции, как (>>=), которые полностью включают несколько функций в суперклассах, могут служить определением для всей соответствующей иерархии.
Раздувание контекста : поскольку существует «причина», по которой Num требуется Show и Eq, это потому, что печать и сравнение равенства чисел довольно распространены. Они строго ортогональны, но их разделение означает, что функции, выполняющие все три вещи, теперь должны указывать все три класса в своем типе. Это технически хорошая вещь, но, опять же, с увеличением степени детализации будут работать сигнатуры типов функций.
Монолитные зависимости : Иерархия классов типов и их суперклассов может быть добавлена, но не изменена или заменена. Если фрагмент кода чувствует необходимость заменить свою собственную версию некоторого класса общего типа - скажем, используя что-то вроде вместо Monad - иерархия обрывается в этой точке; совместимость с кодом, использующим другие определения Monad, должна в некоторой степени обеспечиваться вручную, и любые классы типов, построенные поверх другого определения, должны быть переопределены или переведены, даже если они зависят только от подмножества поведения, которое разделяют оба определения.
Нет четко правильной иерархии : Как следует из вышесказанного, в гранулярности классов необходимо сделать выбор. Например, Pointed действительно должен существовать или достаточно Applicative? Здесь действительно нет ответа, который является универсально идеальным, и не должно быть.
Я подозреваю, что усилия по замене существующих классов типов будут лучше обслуживаться, если сначала решить вышеуказанные проблемы, после чего замена классов типов будет гораздо менее болезненной или даже чуть более формальной. Предложение синонимов класса типов, которое, например, упоминает @luqui, станет важным шагом в этом направлении.