In che modo le entità con un'identità e uno stato persistente mutevole sono modellate in un linguaggio di programmazione funzionale?

Il solito modo di fare cambiamenti di stato in un linguaggio puro come Haskell è di modellarli come funzioni che prendono il vecchio stato e restituiscono una versione modificata. Anche per oggetti complessi, questo è efficiente a causa della strategia di valutazione lenta di Haskell - anche se stai sintatticamente creando un nuovo oggetto, non è copiato nella sua interezza; ogni campo viene valutato solo quando è necessario.

Se hai più di alcune modifiche allo stato locale, le cose possono diventare maldestre, che è il luogo in cui entrano le monadi. Il paradigma monade può essere usato per incapsulare uno stato e le sue modifiche; l'esempio da manuale è il State monad che viene fornito con un'installazione Haskell standard. Si noti, tuttavia, che una monade non è nulla di speciale: è solo un tipo di dati che espone due metodi ( >>= e return ) e soddisfa alcune aspettative (le 'leggi monad'). Sotto il cofano, la monade di stato fa esattamente la stessa cosa: prendi il vecchio stato e restituisci uno stato modificato; solo la sintassi è migliore.

Non sono uno sviluppatore linguistico funzionale, quindi per favore sparami in fiamme se ho sbagliato, ma se è giusto, potrebbe essere un'analogia interessante.

Una volta mi è stato detto che Excel è essenzialmente un linguaggio funzionale. Non sto parlando di VBA e così via, sto parlando di cosa succede a foglio.

Quindi hai input, che possono essere tabulari, singole celle o intervalli nominati, e così via, e attraverso una catena di operazioni si finisce con un risultato, o molti risultati. Cambia un input e subito scorre.

Questa analogia contiene acqua?

Prenderò che stai parlando delle caratteristiche apolidi del puro linguaggio funzionale.

Prendi lo stato iniziale come input, restituisci lo stato finale come output. Niente di fondamentalmente diverso da ciò che fai in una lingua con una nozione di stato, a parte il fatto che sei più esplicito a riguardo e che può essere noioso e meno efficiente (*).

Nota che non devi necessariamente modificare tutte le posizioni che fanno riferimento al tuo oggetto: possono contenere un token e quindi devi solo modificare la struttura dati che mappa i token allo stato corrente. A quel punto, stai implementando un sistema a stato completo che utilizza un linguaggio stateless e recuperi i problemi delle lingue complete di stato.

(*) Per esempio ho cercato - e non ho trovato - la struttura dati che mi permette di restituire in O (1) una copia modificata di una struttura dati indicizzabile con interi consecutivi in O (1) come bene.

In breve, ogni stato di un'entità è la sua entità. Pertanto, nella classica logica aziendale di "ordinamento", esiste un'entità Order e un'entità OrderVersion . Entrambi sono immutabili. La logica che aggiunge un elemento pubblicitario prende la vecchia versione e un nuovo OrderLineItemVersion come input e restituisce una nuova entità OrderVersion .

Rende alcune cose più facili (in particolare la funzionalità "annulla"), ma alcune cose sono più difficili.