Давайте, все же, учитывать контекст нашего канала. Реализации компиляторов встречаются на самых различных ЯП, поэтому конкретный шаблон проектирования я бы не ставил сейчас во главу угла. С точки зрения разработки компиляторов, повторюсь, важнее общий комбинаторный подход, где комбинатор понимается в широком смысле (цитируя Джона Хьюза: «функция, которая строит фрагмент программы из фрагментов программ»). Как это устроено — монады, стрелки, DCG, передача динамического состояния... — вопросы реализации в конкретных ЯП.

Т.е. тебе ничего не мешает выразить монаду на языке с интерфейсами. Тут вопрос именно в том, что система типов должна позволять типы высших порядков, без которых монады, функторы и т.п. - не выразимы.

Тут вопрос в том, насколько просто и безопасно будет переиспользовать комбинаторы в различных подходах.

И что может дать каждый из них, т.к. у всех есть свои трейдоффы.

если имеется ввиду реализации одной и той же логики в разных языках, то больше похоже на заблуждение, хотя припоминаю какую-то старинное исследование, но там не было того же питона

Нет. Монады подчиняются вполне определённым законам композиции в отличие от.

там где в императивных языках пишутся километровые визитеры, в ФП используются сум-типы и сопоставление с образцом

понимаю что можно, только ими невозможно пользоваться, там где они не заложены в язык

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

можно пример?

Ага, но проблема в том, что в процессе разработки компилятора это не те законы, которые мне нужны. И, судя по вот этому обсуждению, скепсис возникает не только у меня :) https://mobile.twitter.com/prof_ilya/status/1230541680819879937

мне лень писать класс визитер и потом создавать четыре визитера

Кстати. Вот комбинаторный парсер - это общеизвестная вещь. А существуют ли комбинаторные генераторы кода?

Почему сложно? Монады изначально использовались для описания эффекта бета-редукции в денотационных моделях нетипизированного lambda-исчисления. С типизированным, кстати, проблем особо и не было, потому что всем хватало STLC, в котором нет проблем с неопределённостью. Теоркат, фактически, пришлось затащить в информатику в отчаянных попытках понять, в каком смысле T может быть равно Т -> T. А потом уже понеслось. Но, кстати, первые описания прочих эффектов: работа с вводом/выводом или с памятью (что особо занимало умы) тоже были даны сначала в бестиповых денотационных конструкциях.

что-то поскромнее мб, в питоне например паттерны почти не используются, в том числе и визитёр, из-за гибкости языка

а потом полтора часа это отлаживают, ага

Да, я именно так и пишу компиляторы. Оно выглядит похоже на БНФ нотацию, но уже для трансляции IR -> язык ассемблера.

это больше про плюсы) питон оч прозрачен для отладки

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

скорее наоборот

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

Ну, в контексте компиляторного чата, вроде как, не важно, какой язык брать. Типы-то стираются :)