Come gestire lo stato in un'applicazione GUI con Haskell

Question

Come gestire lo stato in un'applicazione GUI con Haskell

#1 da (1 voti)

3

Sto usando wxHaskell per creare una semplice interfaccia grafica con componenti tipici come pulsanti, pannelli, ecc.

Quando alcuni di questi componenti eseguono un'azione (come il callback), lo stato generico dell'applicazione può cambiare.

Per mantenere lo stato, sto usando IORef come una sorta di puntatore a una struttura dati generica con tutte le proprietà dello stato self.

Ad ogni modo usare IORef come una sorta di stato mutabile di primo livello non è generalmente considerato una buona soluzione basata sul link . Potrebbe essere meglio stato / stato monad.

wxHaskell è un "collegamento" a una libreria orientata agli oggetti (wxWidgets) e l'uso di una monade di stato è difficile a meno che non sia "agganciato" al thread del ciclo di eventi principale.

Qual è il modo migliore per gestire uno stato generico della GUI con Haskell in un modo di programmazione funzionale?

haskell monad

posta Randomize 28.06.2015 - 17:33

fonte

1 risposta

Leggi altre domande sui tag haskell monad

Eliminazione della dipendenza ciclica Dove memorizzare le impostazioni globali configurabili

score 1 · Answer 1

TL; DR: FRP

La cosa che rende questo non tanto banale quanto in un imperativo impuro è che lo stato non viene solo modificato dalla nostra parte, anche il sistema lo modifica e in tempo reale (ad es. quando l'utente sposta la finestra , o anche solo sposta il cursore). E non possiamo ascoltare gli eventi e aggiornare i nostri valori, perché sono immutabili.

Se fossimo gli unici responsabili per lo stato che sarebbe stato molto più semplice.

Questo è ciò che fa sì che la gente ricorra a IORef s: non sanno cosa fare, e questo modello è l'unica soluzione a cui hanno familiarità - è fantastico in tutte le lingue imperative, dopo tutto. È abbastanza facile, ed è davvero veloce, non è vero? (diversamente dal polling, ad esempio).

Beh, ovviamente non possiamo essere puri qui, la GUI riguarda solo gli effetti collaterali, ma vogliamo provare a rimanere il più puri possibile, e ci piacerebbe davvero farlo con il costrutti funzionali che abbiamo imparato ad amare così tanto (pieghevoli, funzionali, applicativi, a volte frecce), e questo è praticamente ciò che FRP (Functional Reactive Programming) può fare per te.

Ci sono molte librerie FRP là fuori, imo una facile è reactive-banana .

Non riesco a pensare a qualcosa di più idiomatico, tuttavia, se questo è uno stato eccessivo, lo stato mutabile di alto livello non dovrebbe essere la risposta. Manterrei lo stato, direttamente in main , o lo raggrupperò in tipi di dati (con campi IORef ) se ce ne sono troppi e diventa uno zoo di IO.

Suggerimento: non l'ho provato, ma penso che FRP con una libreria di obiettivi possa rendere incredibilmente facile

la gestione dello stato.