F # MailboxProcessor e Functional Design

Question

Se lo stato è considerato una cattiva idea per le funzioni, perché è considerato corretto avere uno stato quando si utilizza un MailboxProcessor?

Per espandere, stavo spiegando la programmazione funzionale a qualcuno, in che modo le funzioni non usano lo stato (nessuna variabile al di fuori della funzione - cioè gli stessi dati per gli stessi dati) e le cose positive che ciò comporta. Ma poi ho pensato a MailboxProcessor e al modo in cui usa la ricorsione per mantenere lo stato tra le chiamate di funzione, e non riesco a riconciliare il motivo per cui va bene in quella situazione.

È un caso che sia il modo meno ostico di mantenere lo stato?

Answer 1

Il male è davvero stato mutabile. Nel caso a thread singolo, lo stato mutabile condiviso indica che le funzioni non possono essere composte in modo sicuro, poiché una chiamata può modificare uno stato che viene poi letto da una seconda chiamata e quindi si otterranno risultati imprevisti. Nel caso a più thread, lo stato mutabile condiviso indica che si ha il potenziale per le condizioni di gara.

La programmazione funzionale generalmente evita la mutazione. Le funzioni possono ancora condividere alcuni stati (ad esempio, la chiusura può catturare uno stato), ma non possono essere mutate. Nel caso a thread singolo, non c'è anche non determinismo. Nel caso multi-thread, praticamente l'unica cosa che si può fare in puro stile funzionale è fare il parallelismo fork-join (e il parallelismo dei dati) che non ha bisogno di uno stato mutabile ed è completamente deterministico.

La programmazione basata su agenti evita anche lo stato mutabile condiviso, ma in un modo diverso. Hai agenti isolati che possono solo condividere messaggi immutabili. Quindi c'è un non determinismo (perché comunicano inviando messaggi), ma si scambiano solo valori immutabili. In effetti, puoi persino usare lo stato mutabile all'interno di un agente, purché non sia condiviso, eviti comunque lo stato mutabile condiviso.