Reader очень помогает, когда оказывается, что нескольким функциям в композиции нужны одни и те же данные. И чтобы они попали вниз по потоку, нужно, получается, снизу возвращать кортеж, а сверху принимать тоже кортеж, и не дай бог, между двумя функциями, которые обрабатывают это разделяемое состояние, оказывается одна, которая не обрабатывает. Тогда она получает состояние только, чтобы передать его в результат, никак не используя. А потом оказывается, что одна из этих функций работает ещё с одним состоянием, которое также нужно в той функции, которая не работает с первым разделяемым состоянием. Вот радости-то!

У меня другой вопрос, почему монада функций называется Ридер

потому что действия могут только читать контекст и не могут писать

Соответственно, Writer может только скидывать значения куда-то, а State это у нас r/w, так?

так

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

с RWS красиво получается, если уже написаны соответствующие типы для входа, выхода и промежуточного состояния (а в некоторых задачах они натурально получаются)

правда, очень ограниченно ридер можно менять контекст (local) и райтер может читать (listen) и менять (censor)

а ещё такое вот есть, стоит ознакомиться
https://www.fpcomplete.com/blog/2017/06/readert-design-pattern/

Моя любимая монада!

А ещё можно над Reader навернуть ContT и оно сможет обновлять контекст как в State

А разве в таком случае все функции в этой цепочке не должны иметь тип Reader a?

Functor & Applicative & Monad with do-notation

Передают тебе привет

Должны

Ну тогда в чем будет отличие от явного таскания контекста?

Это делается неявно

Но в типе-то явно

А почему хочется?

Было Config -> a -> b, стало a -> Reader Config b или вообще MonadReader Config m -> a -> m b