Pourquoi le comité Haskell a-t-il choisi des monades pour représenter les E / S?

Le langage propre utilise des types d'unicité pour gérer les E / S dans un cadre purement fonctionnel. Pourquoi le comité Haskell est-il allé plutôt avec des monades ? Y a-t-il eu d'autres propositions de traitement indiquant que le comité avait enquêté mais qu'il avait décidé de ne pas le faire?

_{Note : Je ne cherche pas une guerre sainte entre les monades et les autres formes d’informatique. Gardons le sujet uniquement sur les choix du comité concernant les E / S.}

Selon Une histoire de Haskell: Être fainéant avec la classe (voir section 7), trois modèles différents ont été initialement envisagés: les flux , les continuations et le "dépassement du monde" (je ne connais pas grand chose à propos de Clean, mais il semble que ce soit la manière de Clean ?)

Le dernier paragraphe de la section 7.2 indique que le concept de type d'unicité n'a pas encore été développé:

Ce modèle «de passage dans le monde» n’a jamais été un sérieux prétendant pour Haskell, car nous n’avons trouvé aucun moyen facile d’assurer un accès «mono-thread» à l’état mondial. (Les concepteurs de Clean ont finalement résolu ce problème en utilisant des «types d'unicité»)

Le concept de monade semble avoir été introduit (réutilisé à partir d'autres travaux) dans les révisions ultérieures de Haskell puisqu'il en a résulté un code plus propre (par rapport aux continuations / flux):

L’approche monadique a rapidement dominé les modèles précédents. Les types sont plus compacts et plus informatifs.

La meilleure explication que j'ai vue est celle de Simon Peyton-Jones: " Tackling the Awkward Squad ".

D'après ce que je me souviens du journal, les problèmes de paresse ont joué un grand rôle dans la décision. (Je ne suis pas sûr si Clean est paresseux de la même façon que Haskell.)