> Она полностью детерминирована.
результат-то разный может возвращаться от вызова к вызову.
при изменении данных в базе

так я про то, что там транзакция открывается снаружи

и никто не меняет состояние в это транзакции

ну, есть термины идемпотентность и ссылочная прозрачность

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

Думаю проще сказать что это обычная функция, чем документировать как детерминированную при таком-то списке условий. Это устраняет риск что список кто-то пропустит или поймёт неправильно. Второй кейс вообще не понял.

Вопрос возник из-за того, что я стал разбираться как люди изолируют эффекты, в частности я смотрел на концепцию functional core imperative shell.

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

Только датомик создает илюзию того, что база данных это значение.  Если есть недостающие сегменты, то он лениво докачивает их по сети.

Я хочу найти какую-то информацию о подобных подходах.
О практически чистых функциях.

И замене обычных данных ленивыми, для отделелния эффектов от логики.

Функцию из случая 1 можно заменить объектом, с интерфейсом хэшмапы, который лениво загружает данные, а потом кэширует.

смотрел в сторону хэндлеров эффектов?

да, есть eff-lang, для хаскеля монада eff
но это гарантированно делает функцию не чистой.

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

* ленивые коллекции с побочным эффектом =)

и конечно не все эффекты можно заменить на ленивые коллекции

Это все не работает. Нужны логи, перехват исключений, и кроме датомика Кассандра и Кафка.

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

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

При этом тут нет dependency inversion

Что упрощает тестирование

Подскажите канал для нубских вопросов по Clojure, типа какой консольный REPL есть приличный с поддержкой автодополнения и возможностью историю команд листать, типа как у racket/ghci/python, please