вопроса, но он как будто в целом про концепцию фп и конкретно про Haskell. Прочитал, что в целом в мире фп нет идеи мутабельного состояния, что вместо мутации стейта мы создаем новый стейт на основе существующего с каким-то изменениями. А как тогда с файловой системой происходит работа? По логике это же мутабельный стейт, который может изменяться не только нашей программой? Или это другое в концепции фп? Или подразумевается, что это уже не часть фп, и за нас это все разруливают готовые библиотеки, ОС и тд? Сорри, если это неподходящий вопрос для этого чата
есть IO монад, который дает возможность выходить во внешний мир и мутировать, как я понял
В целом мире есть (ML-семья языков), это в хаскельной семье скорее нет.
то есть типа для 95% процентов кода мы пишем иммутабельный код, и в 5% используем мутабельный стейт, типа в акторах, в библиотеках, которые работают с файлами и тд?
то есть у фп в целом нет такого требования, что все должно быть иммутабельное? У каких то языков есть, у каких то нет?
да, если нужно прочитать файл, печатать в консоль читать из консоли и т.д. - IO Monad в помощь. он помогает спокойно работать с грязным кодом (с побочкой (side effect))
ФП не может требовать, оно не субъект (: Может требовать препод по ТЯП, или кто-нибудь ещё. В это всё и упирается - а для какой цели вообще это разделение проводится?
по сути мы изолируем мутабельный код от иммутабельного. мутабельный называют tainted а иммутабельный pure их разделяют каким нибудь интерфейсом который выдает либо ожидаемый результат либо сообщает что результат получить не удалось. вроде в learn you a haskell так объяснялось
Соотношение, конечно, не такое, но основная идея в том что мы можем разделить код с эффектами от кода без эффектов. То есть у нас есть логическое разделение по тому, что может совершать подсистема в коде.
правильно, так легче контролировать код и отлавливать ошибки в случае чего
в принципе это и в других языках хорошая практика в том же клине всякие базы данных и инпуты обкладываются валидациями и дата-леерами для перевода между внутренним программным представлением и представлением в окружающем мире. что бы потом можно было уже полагаться на то, что данные корректны, а не валидировать их в каждой функции заново.
какие акторы имеются в виду? если те, что что в Акке или Эрланге, то они тоже могут быть полностью иммутабельны. там чистые данные на входе, чистые на выходе
наверное не про конкретные какие то, в целом читал (не знаю, насколько это корректная информация), что в некоторых системах используются акторы для обмена данными в многопоточных приложениях. Как я понял, как раз в них в этом случае мутабельный стейт, доступ к которому актор контролирует
Не обязательно. Это может быть просто функция которая сама себя вызывает с новым "стейтом" в конце обработки сообщения.
actor counter = recv >>= \req -> print req >> actor (counter + 1)
Обсуждают сегодня