struct Base {
  int x = 0;
  virtual int foo() { x += 1; }
};

struct Derived : Base {
  int foo() { x += 2; }
};

void do_work(Base &x) {
  x.foo();
}

void test() {
  Derived x;
  do_work(x);
}

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

Будет. Через ту же самую таблицу методов. Только это редко бывает необходимым.

Так монады именно как некий интерфейс для композиции значений отлично себя показывают в final tagless стиле.

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

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

А изобретать на каждый эффект свою уникальную DSL может помешать переиспользованию кода

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

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

Вон, даже Аппель в своем компиляторном учебнике успешно обошелся CPS в разделе Continuation-based I/O.

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

Так в реальных приложениях будет и абстрактная интерпретация, и порождение кода из статьи.
Вот здесь у Олега много реальных приложений как раз в контексте нашего чата. И решения приведены с монадами и без.
http://okmij.org/ftp/meta-programming/HPC.html

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

А так я беру, требую:

myProgram :: (Monad m, MyDsl m) => m ()

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

myProgram :: (Monad m, MyDsl m) => m ()

С final tagless интересно, что создаваемые DSL имеют гораздо большую поддержку от хост-языка, чем это было было бы в динамическом ЯП. Даже хост-системой типов удается воспользоваться.
Конечно, никто не говорит, что монады вообще не нужны. В некоторых ЯП это традиционный шаблон проектирования. Я уж не говорю об известной алгебраической структуре — моноиде ("инстансом" которой является монада), без которой действительно никуда :)

Т.е. я пробовал писать как и в стиле полностью со своими tagless final DSL, так и переиспользуя стандартные тайпклассы для композиции значений своих tagless final DSL

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

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

И я с этим согласен.

Кстати, в тему Scala и подхода от Олега: https://github.com/julienrf/effects-without-monads-but-with-dotty

есть что-то почитать по поводу вывода типов? не представляю вообще как такое проворачивать.

В Language Design Patterns есть, в TAPL ещё есть

В той же книге дракона тоже есть

cps - это тоже монадическая конструкция. Не понятно, что такого плохого в обобщениях? Монады многое обобщают, в том числе и DSL.

не нашел такой книги Language Design Patterns

я тебе кидал несколько раз

ну ты историю в лс чистишь, она видимо не сохранилась. пойду поищу лучше.

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

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

Далее, для реализации какого-нибудь RISC-V можно ввести init (начальное состояние) и next (переход из состояния в состояние). Для практической реализации остается только рассказать про хвостовую рекурсию и CPS.