F# MailboxProcessor и функциональный дизайн
Если состояние рассматривается как плохая идея для функций, почему считается, что хорошо иметь состояние при использовании MailboxProcessor?
чтобы расширить, я объяснял функциональное программирование кому - то, как функции не используют состояние (никаких переменных вне функции-т. е. те же данные для тех же данных) и хорошие вещи, которые это приносит. Но потом я подумал о MailboxProcessor и о том, как он использует рекурсию для сохранения состояния между вызовами функций, и я не могу совсем смиритесь с тем, что в этой ситуации все в порядке.
является ли это наименее плохим способом сохранения состояния?
1 ответов
зло действительно общее изменяемое состояние. В однопоточном случае общее изменяемое состояние означает, что функции не могут быть безопасно составлены - потому что один вызов может изменить некоторое состояние, которое затем считывается вторым вызовом, и поэтому вы получите неожиданные результаты. В многопоточном случае общее изменяемое состояние означает, что у вас есть потенциал для условий гонки.
функциональное программирование вообще избегает мутации. Функции могут по-прежнему разделять некоторое состояние (например, закрытие может захват состояния), но его нельзя мутировать. В однопоточном случае также отсутствует недетерминизм. В многопоточном случае единственное, что вы можете сделать в чистом функциональном стиле,-это сделать параллелизм fork-join (и параллелизм данных), который не нуждается в изменяемом состоянии и полностью детерминирован.
программирование на основе агента также позволяет избежать общего изменяемого состояния, но по-другому. У вас есть изолированные агенты, которые могут только делиться неизменяемые сообщения. Так существует некоторый недетерминизм (потому что они общаются, отправляя сообщения), но они обмениваются только неизменными значениями. Фактически, вы даже можете использовать изменяемое состояние внутри агента - пока оно не является общим, вы все равно избегаете общего изменяемого состояния.