AZ
monad laws говорят про опредлеенное поведенеи функций bind и pure
Size: a a a
2020 February 08
AZ
я ни одной из них тут не вижу
AZ
в хаскелле например есть функция
lefts :: [Either a b] -> [a]AZ
при том что
e вообще не участвует в монадических функциях над Eitherr
Как я понял, логика была такая Option::and_then - это bind, поэтому Iterator::and_then должно быть == Iterator::flat_map. Но есть операции, которые не влезают в монаду. А имена им давать надо.
AZ
да, но не надо им отдавать имена зарезервированные под местный bind
AZ
если в расте на всех распростаренных структурах (Option/Result/Future/...) бинд называется and_then, то называть им какую-то иную операцию - не стоит
r
Ммм. Кем зарезервированные?
AZ
red75prime
Ммм. Кем зарезервированные?
кортима
AZ
использовала это название
r
...там, где оно отражало суть операции. То, что and_then в монаде List - это Iterator::flat_map не такое уж и распространённое знание
AZ
Стоит сделать его более распространенным
AZ
потому что map().flatten() и на опшне/резалте
r
Как я уже и говорил, абстрактные операции на монадах в применении к конкретным монадам дают совершенно различные знакомые программистам операции: (используя примеры торта)
;, await, ?, and_then, flat_map, и т.п.AZ
только это плюс, а не минус
AZ
собсна я в статье и планирую поругать накостыленный синтаксис для конкретных монад
AZ
ортогональный однообразный синтаксис? Не, не слышал
AZ
что до разного поведения - то две виртуальные функции от одного общего предка тоже могут делать разные вещи. никого это не удивляет
r
Лисп со скобочками
AZ
ни одной скобочки не написал в процессе демонстрации