Pull to refresh

Comments 11

В оригинале, функторы идут после монад, что мне показалось неверным. Всякая монада - это функтор, но не всякий функтор - это монада

Другими словами, монады – это подмножество функторов. Если повествование идёт об частного к общему, то начинать с монад было бы логичнее.

Обычно объясняют от простого к сложному. Если идти от теории (монада это моноид в категории эндофункторов), то функторы объяснить проще - как более примитивное. Если от практики, то действительно проще будут монады - как более конкретное.

Вы меня, конечно, заставили задуматься. Я как раз хотел идти от общего к конкретному, ну просто по сумме свойств. То есть функтор это объект со свойством A, это свойство заключается в том то. Монада плюсом к свойству A еще имеет свойство B, смотрите в чем отличия. У самого автора в оригинале в конце поста про функторы идет ссылка на пост про монады, как продолжение чтения (то есть с 3ей части серии, на 1ую). Что мне показалось свидетельством нарушенного порядка.

Что-то мне кажется, что выбор языка из семейства ML для демонстрации теорката - плохая затея.
Потому что, внезапно, в SML и OCaML словом "функтор" называются параметризованные модули.
Да, в F# до них не доросли, но... кто знает, вдруг дорастут?

Я бы хотел обратить внимание на подход, выбранный автором, он не пытается демонстрировать теоркат, он показывает суть паттерна, который, по совпадению, тоже называется функтор.

Ещё один важный момент.
Поскольку в F# нет ни параметризованных модулей, ни классов типов, то нельзя просто так взять и ввести сущность "функтор" или "монада". Только duck typing. Если некий параметризованный тип ведёт себя, как функтор, - это функтор. Но имена служебных функций будут разные - Option.map, List.map...

Как писать обобщённый код, который с любым функтором (или монадой) будет работать единообразно?

Как писать обобщённый код, который с любым функтором (или монадой) будет работать единообразно?

Вот так, например https://fsprojects.github.io/FSharpPlus/generic-doc.html. Реализацию можно глянуть в исходниках, там не так все сложно. В итоге, достаточно описать тип и определить для него пару методов, чтобы обобщённый функции и Computation Expressions работали с вашим типом.

Но в хаскеле все поизящнее, да

Обалдеть! Втащили в фа-диез настолько обобщённые функции.
В исходники надо въезжать, конечно. Там какая-то дотнетная магия.
Чтобы для пользователя всё выражалось одним словом, нужна гора писанины под капотом. Но приятно, что такие возможности всё-таки существуют.

Вообще, как человек, испорченный/очарованный хаскеллом, я с болью смотрю на эти гроканья.
Система типов должна быть достаточно гибкой, чтобы вместить в себя абстракции более высокого уровня, чем параметризованный тип.
Как вариант, она может быть максимально пофигистичной - вплоть до нетипизированного лямбда-исчисления и очень чистых рук программиста, чтоб тот сам следил за корректностью.
Питон с его рантаймовыми типами и C++ с его шаблонами.
В питоне, опять же, есть синтаксис list/generator comprehensions, поверх которого можно с любыми монадами работать, а не только со списком.

У меня тоже первая мысль была, что в статье про монады явно не хватает хаскеля и теорката.

Но собственно какой в этом прикладной смысл? Ни кто же не рассказывает про абелевы группы и копродакты, показывая как в языке использовать, допустим, сложение.

Арифметикой Пеано, однако, пользуются (пользовались) для всякой магии на шаблонах С++.
Это не теоркат, а противоположная крайность, но всё-таки :)

Дело не в том, чтобы подвести базис под тезис и продемонстрировать теоркат.
А в том, что абстракции высокого уровня позволяют писать единообразный, легко переиспользуемый и легко настраиваемый код.
Монада (и её брат - аппликативный функтор) таковыми являются. А теоркатовость - это приятный и полезный бонус.

Надо абстрагироваться от контейнера? Пожалуйста.
Надо подклеить служебные данные? Пожалуйста.
Надо изменить поведение для каждого элемента, сохранив структуру алгоритма? Опять пожалуйста.

А вот почему - если следовать определённым правилам - мы получаем непротиворечивую обвязку? На этот вопрос уже отвечает теоркат.

Хаскелл интересен тем, что это площадка для обкатывания всяких теоретических изысков "а вдруг зайдёт?" Или не зайдёт.
Монада просто уж очень хорошо зашла.
А, например, стрелки, насколько я понимаю, не очень зашли.

Но, повторю: главное - это выделять абстракцию высокого уровня, паттерн программирования.
А будет за ним стоять стройная теория или ad-hoc, чистая эмпирика-эклектика, дело второе.

Sign up to leave a comment.

Articles