А вот тут Вы передёрнули. Полная фраза "For example, using a monadic sequencing combinator for parsers avoids the messy manip-
ulation of nested tuples of results present in earlier work."

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

С итератором возникнут проблемы с откатами, например. То есть, о должен быть посложнее быть устроен. А как именно, как раз и помогают монадические законы понять. Это просто математика, как математика чисел, логики и прочего.

Лично мне помогает, хоть на Bash я пишу, хоть на Си. Пэтому всем рекомендую практиковать.

Ну вообще на императивных языках тоже интерпретаторы языка выражений пишутся. Но они конечно жутко некрасивыми для вас будут, даже если для императивщиков будут нормальными. Потому что не используют монады.

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

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

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

Вы подозреваете у меня злой умысел, в то время как я действительно не нашел других доводов в пользу монад у автора :)

Ну если монадические законы без собственно монад, то это уже другой разговор. Потому что мне представляются монады на Си как что-то совсем ужасное. Да, итератор может и посложнее будет устроен, но эта сложность весьма субъективна, для кого-то монада парсера будет куда сложнее.

А какие тут другие существенные преимущества?

На мой взгляд, первичен, все-таки, комбинаторный подход. Если разработчик понимает преимущества комбинаторного программирования, то, при необходимости, конкретные шаблоны проектирования (в духе монадной bind) он, походя, переизобретет, не отвлекаясь от прикладной задачи.

Для меня хорошим примером является вот эта реализация синт. анализатора Оберона: https://github.com/vladfolts/oberonjs/blob/master/src/grammar.js

Ее автор ничего не знал ни о монадах, ни о PEG, когда писал этот код. Обычный рядовой разработчик на JS. И результат он получил, исходя из собственного чувства прекрасного :)

Так вот именно. Bind переизобретается очень часто. Имеет смысл это изучить и практиковать

Там целый абзац про это
Taking the monadic approach further, the monad of parsers can be expressed in a modular way in terms of two simpler monads. The immediate benefit is that the basic parser combinators no longer need to be defined explicitly. Rather, they arise automatically as a special case of lifting monad operations from a base monad m to a certain other monad parameterised over m. This also means that, if we change the nature of parsers by modifying the base monad (for example, limiting parsers to producing at most one result), then new combinators for the modified monad of parsers also arise automatically via the lifting construction.

А если человек переизобретает bind, одначает ли это, что он не пользуется монадой парсера?

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

Можем ли мы считать, что мы всех убедили, что монады при парсинге полезны?

Это полезность в общем случае уровня "оказывается, я всю жизнь говорил прозой!" :)

но человек же не сможет больше утверждать, что проза не нужна?

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

а где почитать про комбинаторы?