Отличный пример того, как Хаскель позволяет реализовать сложный функционал в виде библиотеки. Во многих языках пришлось бы выбирать между непрактичным синтаксисом и добавлением поддержки на уровне языка. А здесь STM от разработчиков компилятора выглядит точто так же, как и STM от стороннего исследователя.
Вопрос #1: найдутся ли достаточно рискованные люди, чтобы попытаться при помощи такого подхода превзойти производительность существующей реализации STM в отдельных случаях?
Вопрос #2: реализация на С++ будет пытаться в точности повторить описанный подход (с операцией bind и множеством вложенных лямбд)? Или для постоения AST в плюсах есть какие-то трюки, чтобы сделать синтаксис более читаемым?
#1 Я таки хочу сделать оптимизацию своей STM и прогнать бенчмарки. Но вряд ли буду этим заниматься раньше мая, так что если есть рисковые люди, то welcome.
#2 В С++ все очень плохо с монадами, потому что нет do-нотации, а делать все на лямбдах — очень неуклюже. Но выбора у меня нет, мне нужен именно комбинаторный STM, так что без вариантов: bind, лямбды, вот это вот все. То есть, порт на C++ концептуально один в один, но отличия в синтаксисе все же будут. Еще много проблем с тем, что в С++ нет ADT, и работа со сложными типами превращается в какой-то сущий ад. Тем не менее, мне уже удалось реализовать почти все, что я хотел, и последним штрихом я добавляю разные комбинаторы, пытаюсь придумать более простой синтаксис, а также портирую задачу обедающих философов. Иными словами, я на финишной прямой.
Ох, корутинов мне еще не хватало! Они уже зарелизены, или надо тащить экспериментальные либы/компиляторы? Это те, которые Нишанов делал? Он, кажется, компилятор от MS использовал.
Что-то я не вижу между ними какой-либо существенной разницы, которая указывала бы на «линейность» (что это вообще значит). А другие монады?
Cont?
Free?
Reader?
Writer?
Software Transactional Memory на Free-монадах