Perché il comitato Haskell ha scelto le monadi per rappresentare l'I / O?

Il linguaggio Clean utilizza tipi di unicità per gestire l'I / O in un ambiente puramente funzionale. Perché invece il comitato Haskell andò con le monadi ? Vi erano altre proposte di gestione che indicavano che la commissione aveva indagato ma deciso contro?

_{Nota : non sto cercando una guerra santa tra monadi e altre forme di elaborazione. Manteniamo l'argomento solo sulle scelte del comitato per quanto riguarda l'I / O.}

Secondo A History of Haskell: Being Lazy With Class (vedi sezione 7) inizialmente sono stati considerati tre diversi modelli: stream , continuazioni e "passaggio del mondo" (non so molto su Clean, ma sembra che questo sia il modo Clean ?).

L'ultimo paragrafo della sezione 7.2 indica che il concetto di tipo di unicità non è stato sviluppato in questo momento:

Questo modello "di passaggio del mondo" non è mai stato un serio contendente per Haskell, perché non abbiamo visto un modo semplice per garantire l'accesso "single-thread" allo stato mondiale. (I designer Clean alla fine hanno risolto questo problema attraverso l'uso di "tipi di unicità")

Il concetto di monadi sembra essere stato introdotto (riutilizzato da altri lavori) nelle successive revisioni di Haskell poiché ha portato a un codice più pulito (rispetto alle continuazioni / flussi):

L'approccio monadico ha rapidamente dominato i modelli precedenti. I tipi sono più compatti e più informativi.

La migliore spiegazione che ho visto è " Tackling the Awkward Squad " di Simon Peyton-Jones .

Da quanto ricordo dal giornale, le questioni relative alla pigrizia hanno avuto un ruolo importante nella decisione. (Non sono sicuro che Clean sia pigro per impostazione predefinita allo stesso modo di Haskell.)