бизнес-логику и описать это в чистом виде, а эффекты вытолкать на уровень интерпретатора. Нет проблем, берём FM/TF и пишем нечто типа:
foo :: BizM m => m ()
foo = do
mv <- get' "foo"
case mv of
Nothing -> return ()
Just v -> multi' $ do
put "foo1" v
put "foo2" v
Описываем операции multi', put и get в абстрактной монаде BizM и всё прекрасно работает.
Но что если я хочу сделать многопоточность на уровне бизнес-логики, то есть реализовать операции spawn и join? Как писать интерпретаторы для таких операций? Есть ли пример подобной реализации EDSL?
Прошу прощения за Хаскель, он просто чуть компактнее.
тот ТФ, который тофу пропагандировал, предполагал, что для разных операций будут разные баунды на m. и тут просто пишется еще пара тайпклассов Spawns m, Joins m и добавляются в список баундов
Так, то есть сигнатура ˋspawn:: (() -> m a) -> m aˋ это вполне штатная вещь для Тофу? Если так, это хорошо. Чтобы избежать проблемы XY я опишу, что я хочу получить. Есть программа, она создаёт потоки, строит разные структуры данных, в том числе библиотечные, и по-всякому к ним обращается. Хочется выделить некоторое чистое ядро и подвергнуть его множеству различных тестовых сценариев, чтобы, скажем, убедиться, что нет гонок. То есть эти тестовые сценарии должны уметь создавать некоторые детерминированные псевдо-потоки, и в этих псевдо-потоках нужно, чтобы события происходили в определённом порядке. Подход алгоритмов в виде структур данных мне нравится (и FM, и TF), но в случае со spawn я пока не знаю, как это сработает.
Спасибо за ответ, буду смотреть.
ну тут две разных сигнатуры defer[A](=> F[A]): F[A] и start[A](F[A]): Daemon[F, A] где Daemon - аналог Fiber
Обсуждают сегодня