Кто-нибудь когда-нибудь сталкивался с Трансформатором Монад в дикой природе?

Сообщество Haskell разделились по этому поводу.

• Джон Хьюз сообщает, что ему легче обучать монадным преобразователям, чем монадам, и что его ученики лучше справляются с подходом «сначала преобразователи».

• Разработчики GHC обычно избегают монадных преобразователей, предпочитая сворачивать свои собственные монады, которые объединяют все необходимые им функции. (Мне только сегодня недвусмысленно сказали, что GHC не будет использовать преобразователь монад, который я определил три дня назад.)

Для меня преобразователи монад во многом похожи на программирование без точек (т.е. программирование без именованных переменных), что имеет смысл; в конце концов, они как раз беспроблемное программирование на уровне типов. Мне никогда не нравилось программирование без точек, потому что полезно иметь возможность вводить случайное имя.

То, что я наблюдаю на практике,

• Количество преобразователей монад, доступных на Hackage, очень велико, и большинство из них довольно простые. Это классический пример проблемы, когда сложнее изучить большую библиотеку, чем катать собственные экземпляры.

• Такие монады, как Writer, State и Environment, настолько просты, что я не вижу особой пользы от преобразователей монад.

• Превосходство монадных трансформаторов - в модульности и многократном использовании. Это свойство прекрасно продемонстрировали Лян, Худак и Джонс в их знаменитой статье "Monad Трансформаторы и модульные интерпретаторы ».

Являются ли монадные преобразователи лучшей практикой при решении этих общих задач, упомянутых выше?

Я бы сказал нет. Преобразователи монад лучше всего там, где у вас есть линейка продуктов связанных абстракций, которые вы можете создать, составив и повторно используя преобразователи монад по-разному. В таком случае вы, вероятно, разработаете ряд преобразователей монад, которые важны для вашей проблемной области (например, тот, который был отклонен для GHC), и вы (а) составите их несколькими способами; (б) добиться значительного повторного использования большинства трансформаторов; (c) инкапсулируют что-то нетривиальное в каждый преобразователь монад.

Мой преобразователь монад, который был отклонен для GHC, не отвечал ни одному из критериев (a) / (b) / (c) выше.

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

Думаю, это немного преувеличение:

• Использовать конкретный стек монад преобразователя не сложнее, чем простую монаду. Просто подумайте о слоях \ стеках, и все будет в порядке. Вам почти всегда не нужно поднимать чистую функцию (или конкретное действие ввода-вывода) более одного раза.
• Как уже упоминалось, скройте свой стек Monad в новом типе, используйте обобщенное наследование и скройте конструктор данных в модуле.
• Старайтесь не использовать конкретный стек Monad в сигнатуре типа функции, напишите общий код с классами типа Monad, такими как MonadIO, MonadReader и MonadState (используйте расширение гибких контекстов, которое стандартизировано в Haskell 2010).
• Используйте библиотеки, такие как fclabels, для уменьшения шаблонных действий, которые обращаются к частям записи в монаде.

Преобразователи монад - не единственные варианты, вы можете написать собственную монаду, используя монаду-продолжение. У вас есть изменяемые ссылки / массивы в IO (глобальный), ST (локальный и управляемый, без действий IO), MVar (синхронизация), TVar (транзакционный).

Я слышал, что потенциальные проблемы эффективности с преобразователями Monad можно уменьшить, просто добавив прагмы INLINE для связывания / возврата в исходный код библиотеки mtl / transformers.

Когда я изучал монады, я создал приложение, используя стек StateT ContT IO, чтобы создать библиотеку моделирования дискретных событий; продолжения использовались для хранения монадических потоков, при этом StateT содержал очередь выполняемых потоков, а другие очереди использовались для приостановленных потоков, ожидающих различных событий. Это сработало довольно хорошо. Я не мог понять, как написать экземпляр Monad для оболочки newtype, поэтому я просто сделал его синонимом типа, и это сработало очень хорошо.

В наши дни я, наверное, скатал бы свою монаду с нуля. Однако всякий раз, когда я это делаю, я обнаруживаю, что смотрю на «Все о монадах» и источник MTL, чтобы напомнить мне, как выглядят операции связывания, так что в некотором смысле я все еще думаю в терминах стека MTL, хотя результат это кастомная монада.

Недавно я «упал» на композицию монад в контексте F #. Я написал DSL, сильно полагаясь на монаду состояния: все компоненты полагаются на монаду состояния: синтаксический анализатор (монада синтаксического анализатора на основе монады состояния), таблицы сопоставления переменных (более одной для внутренних типов), таблицы поиска идентификаторов. И поскольку все эти компоненты работают вместе, они полагаются на одну и ту же монаду состояний. Поэтому существует понятие композиции состояний, которое объединяет различные локальные состояния, и понятие средств доступа к состоянию, которые придают каждому алгоритму свою собственную видимость состояния.

Изначально дизайн действительно был «всего лишь одной большой государственной монадой». Но затем мне стали нужны состояния только с локальным временем жизни, но все еще в контексте «постоянного» состояния (и опять же, все эти состояния управляются монадами состояний). Для этого мне действительно нужно было ввести преобразователи монад состояния, которые увеличивают состояние и вместе адаптируют монады состояния. Я также добавил преобразователь для свободного перемещения между монадой состояния и монадой состояния продолжения, но я не стал его использовать.

Поэтому отвечу на вопрос: да, трансформеры монад существуют в «дикой природе». Тем не менее, я категорически против использования их «из коробки». Напишите свое приложение с помощью простых строительных блоков, используя небольшие мосты ручной работы между модулями. Если вы все же в конечном итоге используете что-то вроде преобразователя монад, это здорово; Не начинайте оттуда.

И о типовых сигнатурах: я стал думать об этом типе программирования как о чем-то очень похожем на игру в шахматы с завязанными глазами (и я не шахматист): ваш уровень навыков должен быть таким, чтобы вы "видели" свои функции и типы, подходящие друг к другу. Сигнатуры типов в конечном итоге отвлекают, если только вы явно не хотите добавить ограничения типа по соображениям безопасности (или потому, что компилятор вынуждает вас указать их, например, с записями F #).

Я считаю это заблуждением, только монада IO не чистая. монады наподобие Write / T / Reader / T / State / T / ST все еще остаются чисто функциональными.

Мне кажется, что существует несколько понятий относительно термина «чистый / нечистый». Ваше определение «IO = unpure, все остальное = чисто» звучит аналогично тому, о чем говорит Пейтон-Джонс в «Эффектах приручения» (http://ulf.wiger.net/weblog/2008/02/29/peyton-jones-taming-effects-the-next-big-challenge/). С другой стороны, Haskell реального мира (на последних страницах главы о преобразователе монад) противопоставляет чистые функции монадическим функциям в целом, утверждая, что вам нужны разные библиотеки для обоих миров. Кстати, можно утверждать, что ввод-вывод также является чистым, его побочные эффекты инкапсулируются в функцию состояния с типом RealWorld -> (a, RealWorld). В конце концов, Haskell называет себя чисто функциональным языком (включая ввод-вывод, я полагаю :-).)

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

Итак, что-то, что имеет тенденцию быть довольно глобальным, например, журнал или конфигурацию, вы бы предложили поместить в монаду ввода-вывода? Глядя на (правда, очень ограниченный набор) примеров, я прихожу к мысли, что код Haskell имеет тенденцию быть либо чистым (то есть вовсе не монадическим), либо монадой ввода-вывода. Или это заблуждение?

Я считаю это заблуждением, только монада IO не чистая. монады наподобие Write / T / Reader / T / State / T / ST все еще остаются чисто функциональными. Вы можете написать чистую функцию, которая использует любую из этих монад внутри, как в этом совершенно бесполезном примере:

foo :: Int -> Int
foo seed = flip execState seed $ do
    modify $ (+) 3
    modify $ (+) 4
    modify $ (-) 2

Все, что это делает, - это неявно распределять / связывать состояние, то, что вы бы сделали вручную явно, нотация do здесь просто дает вам приятный синтаксический сахар, чтобы он выглядел императивным. Здесь вы не можете выполнять какие-либо действия ввода-вывода, вы не можете вызывать какие-либо внешние функции. Монада ST позволяет вам иметь реальные изменяемые ссылки в локальной области видимости, имея при этом чистый функциональный интерфейс, и вы не можете выполнять какие-либо действия ввода-вывода в нем, он все еще остается чисто функциональным.

Вы не можете избежать некоторых действий ввода-вывода, но вы не хотите возвращаться к вводу-выводу для всего, потому что это то, куда может пойти все, ракеты могут быть запущены, у вас нет контроля. В Haskell есть абстракции для управления эффективными вычислениями с разной степенью безопасности / чистоты, монада ввода-вывода должна быть последним средством (но вы не можете полностью избежать этого).

В вашем примере я думаю, вам следует придерживаться использования преобразователей монад или монад, сделанных на заказ, которые делают то же самое, что и их компоновка с помощью преобразователей. Я никогда не писал настраиваемую монаду (пока), но я довольно часто использовал преобразователи монад (мой собственный код, не на работе), не беспокойтесь о них так сильно, используйте их, и это не так плохо, как вы думаете .

Вы видели главу из Real World Haskell, в которой используются преобразователи монад ?