Critica della monade IO considerata come una monade di stato che opera nel mondo

45

Il IO monad in Haskell viene spesso spiegato come una monade di stato in cui lo stato è il mondo. Quindi un valore di tipo IO a monad viene visualizzato come qualcosa come worldState -> (a, worldState) .

Qualche tempo fa ho letto un articolo (o un post di un blog / mailing list) che ha criticato questo punto di vista e fornito diversi motivi per cui non è corretto. Ma non riesco a ricordare né l'articolo né i motivi. Qualcuno sa?

Modifica: L'articolo sembra perso, quindi iniziamo a raccogliere vari argomenti qui. Sto iniziando una taglia per rendere le cose più interessanti.

Modifica: L'articolo che stavo cercando è Affrontare la squadra scomoda: input / output monadico, concorrenza, eccezioni e chiamate in lingua straniera in Haskell di Simon Peyton Jones. (Grazie alla risposta di TacTics.)

    
posta Petr Pudlák 20.08.2012 - 09:33
fonte

5 risposte

30

Il problema con IO a = worldState -> (a, worldState) è che se ciò fosse vero, potremmo provare che forever (putStrLn "Hello") :: IO a e undefined :: IO a sono uguali. Ecco la prova per gentile concessione di dolio (2010, irc):

forever m
 =
m >> forever m
 =
fix (\r -> m >> r)
 = {definition of >> for worldState -> (a, worldState)}
fix (\r -> \w -> r (snd $ m w))

Lemma: (\r w -> r (snd $ m w)) ⊥ = ⊥

(\r w -> r (snd $ m w)) ⊥
  =
\w -> ⊥ (snd $ m w))
  =
⊥ . snd . m
  =
⊥

Pertanto forever m = fix (\r -> \w -> r (snd $ m w)) = ⊥

In particolare forever (putStrLn "Hello") = ⊥ e quindi forever (putStrLn "Hello") e undefined sono programmi equivalenti. Tuttavia, chiaramente non dovrebbero essere considerati programmi equivalenti, in teoria o in pratica.

Si noti che questo modello è sbagliato anche senza invocare la concorrenza.

    
risposta data 05.09.2012 - 21:51
fonte
12

Ecco una risposta banale: qualsiasi modifica allo stato della monade di stato è dovuta a qualsiasi azione eseguita nella monade. Se davvero il "WorldState - > (a, WorldState) "la spiegazione rivendica la stessa proprietà, con WorldState che è un valore puro che solo la monade IO cambia, è sbagliato. I cambiamenti di orario, il contenuto dei file, lo stato delle maniglie, ecc. Possono cambiare indipendentemente da ciò che accade nella monade IO. Questo è il punto della monade IO. Il fatto che GHC passi attorno a un valore di RealWorld (o che lo fosse) è garantire che le cose siano in ordine, per quanto ne so, se questo (potrebbe essere solo qualcosa da inserire nel valore ST).

    
risposta data 04.09.2012 - 16:43
fonte
11

Ho scritto un post sul blog su come modellare IO come una forma di coroutine asimmetrica che comunica con il sistema di runtime per la tua lingua. (È certamente la terza parte di una serie)

link

Quel post copre un po 'il motivo per cui è scomodo ragionare sulla semantica del "passaggio del mondo".

    
risposta data 04.09.2012 - 18:18
fonte
8

Vedi Affrontare la Squadra Impressionante .

La grande ragione è che i modelli di stato RealWorld della monade IO non funzionano bene con la concorrenza. SPJ in questo leggibile classico favorisce l'utilizzo di una semantica operativa per comprenderlo.

    
risposta data 04.09.2012 - 18:25
fonte
5

La lamentela principale sui modelli di stato RealWorld è che, come dice TacTics, il passaggio del mondo non necessariamente funziona con la concorrenza. Ma Wouter Swierstra e Thorsten Altenkirch hanno mostrato come ragionare sulla concorrenza come effetto "world-passing", con una sequenza fissa ma arbitraria di thread interleaving nel loro paper "Beauty in the Beast: A Functional Sematics for the Awkward Squad": < a href="http://www.staff.science.uu.nl/~swier004/Publications/BeautyInTheBeast.pdf"> link

Il codice corrispondente a questo è su Hackage come IOSpec: link

Penso che la tesi di Wouter vada più nel dettaglio: link

    
risposta data 04.09.2012 - 18:37
fonte

Leggi altre domande sui tag