F # MailboxProcessor und Functional Design

Question

Wenn Zustand als eine schlechte Idee für Funktionen angesehen wird, warum ist es in Ordnung, einen Zustand zu haben, wenn Sie einen MailboxProcessor verwenden?

Um zu erweitern, ich erklärte funktionale Programmierung zu jemandem, wie Funktionen nicht verwenden Zustand (keine Variablen außerhalb der Funktion - d. H. Gleiche Daten für die gleichen Daten in) und die guten Dinge, die dies bringt. Aber dann habe ich über MailboxProcessor und die Art und Weise nachgedacht, wie Rekursion verwendet wird, um den Status zwischen Funktionsaufrufen zu erhalten, und ich kann nicht ganz nachvollziehen, warum es in dieser Situation okay ist.

Ist es ein Fall davon, der am wenigsten schlechte Weg des persistierenden Staates zu sein?

Answer 1

Das Böse ist wirklich shared veränderbarer Zustand. Im single-threaded Fall bedeutet shared mutable state, dass Funktionen nicht sicher zusammengesetzt werden können - weil ein Aufruf einen Zustand ändern kann, der dann von einem zweiten Aufruf gelesen wird und Sie dadurch unerwartete Ergebnisse erhalten. In einem Multithread-Fall bedeutet der gemeinsame veränderbare Status, dass Sie potentielle Rennbedingungen haben.

Funktionelle Programmierung vermeidet generell Mutationen. Funktionen können immer noch einen bestimmten Zustand teilen (z. B. können Schließungen einen Zustand erfassen), sie können jedoch nicht mutiert werden. Im Singlethread-Fall gibt es auch keinen Nicht-Determinismus. In Multi-Threading-Fällen ist praktisch nur die Funktionalität von Fork-Join-Parallelität (und Datenparallelität) möglich, die keinen veränderbaren Status erfordert und vollständig deterministisch ist.

Die agentenbasierte Programmierung vermeidet den gemeinsamen veränderbaren Zustand, aber auf andere Weise. Sie haben Agenten isoliert, die nur unveränderliche Nachrichten teilen können. Es gibt also einen gewissen Nicht-Determinismus (weil sie kommunizieren, indem sie Nachrichten senden), aber sie tauschen nur unveränderliche Werte aus. Tatsächlich können Sie sogar einen veränderlichen Status in einem Agenten verwenden - solange er nicht geteilt wird, vermeiden Sie den gemeinsamen veränderbaren Status.