Ответ 1
Это должно было случиться с предложением Applicative-Monad (которое дошло до GHC 7.10). Тем не менее, существует техническая проблема, в которой введите роли в GHC который отложил на неопределенный срок выполнение того, что вы предлагаете.
Хорошо известно, что (>>=)
может быть реализовано с использованием fmap
и join
, а join
может быть реализовано с помощью >>=
. Есть ли какая-то причина, по которой мы не определяем класс Monad
с join
включенным и использующим следующие определения по умолчанию?
join x = x >>= id
x >>= f = join $ f <$> x
Это позволило бы минимальному определению включить либо просто (>>=)
, либо join
, а не форсировать (>>=)
. Может быть немного полезно, учитывая теорию категорий, как правило, благоприятствует join
.
Обычный аргумент против модификации классов заключается в том, что мы нарушаем обратную совместимость. Однако в этом случае этого не произойдет - добавим возможность определения Monad
с помощью join
.
Это должно было случиться с предложением Applicative-Monad (которое дошло до GHC 7.10). Тем не менее, существует техническая проблема, в которой введите роли в GHC который отложил на неопределенный срок выполнение того, что вы предлагаете.