Этот вопрос исходит из этого ответа в примере функтора, который является аппликативным, но не монадой. Утверждается, что
data PoE a = Empty | Pair a a deriving (Functor,Eq)
не может иметь экземпляр монады, но я не вижу этого:
instance Applicative PoE where
pure x = Pair x x
Pair f g <*> Pair x y = Pair (f x) (g y)
_ <*> _ = Empty
instance Monad PoE where
Empty >>= _ = Empty
Pair x y >>= f = case (f x, f y) of
(Pair x' _,Pair _ y') -> Pair x' y'
_ -> Empty
Фактическая причина, по которой я считаю, что это монада, состоит в том, что она изоморфна Maybe (Pair a)
с Pair a = P aa
. Они оба являются монадами, оба являются общими, поэтому их композиция также должна формировать монаду. О, я только узнал не всегда.
Какой контр-пример не соответствует закону монады? (и как найти это систематически?)
Я не ожидал такого интереса к этому вопросу. Теперь я должен решить, принимаю ли я лучший пример или лучший ответ на "систематическую" часть.
Между тем, я хочу визуализировать, как join
работает для более простой Pair a = P aa
:
P
________/ \________
/ \
P P
/ \ / \
1 2 3 4
он всегда принимает внешний путь, давая P 1 4
, более широко известный как диагональ в матричном представлении. Для монадской ассоциации мне нужны три измерения, визуализация дерева работает лучше. Взятый из ответа на ци, это неудачный пример объединения, и как я могу его понять.
Pair
_________/\_________
/ \
Pair Pair
/\ /\
/ \ / \
Pair Empty Empty Pair
/\ /\
1 2 3 4
Теперь вы join. fmap join
join. fmap join
, сначала сбрасывая нижние уровни, для join. join
join. join
коллапса из корня.