Scherrer, Chad writes:

...

From: Cale Gibbard [mailto:cgibbard@gmail.com] See: http://haskell.org/pipermail/haskell-cafe/2003-January/003794.html

The OI comonad as previously envisioned breaks referential transparency. I/O just doesn't seem to be something which one can easily do comonadically, since once coeval/extract is applied, you're back to plain values, and there's no imposition of sequencing.

- Cale

Hmm, I hadn't seen that. The asymmetry is pretty frustrating in that case.

After poking around a bit more, I (re)discovered some discussion of this on Hawiki: http://www.haskell.org/hawiki/CoMonad

After reading Dave Menendez's comments, I'm wondering... If we consider IO a = Realworld -> (Realworld, a) then wouldn't we dually have something like OI a = (Realworld, Realworld -> a)?

Could this be what screws things up? Right now it seems like OI is acting like it has the same type as IO, with a different name.

Aside from the product comonad and the exponent (reader) monad, I don't think we'll find much overlap between monad and comonad functionality. It's been said that monads describe effects that propagate outwards, whereas comonads describe effects that propagate inwards. My guess is that comonadic IO would look more like dataflow programming. -- David Menendez | "In this house, we obey the laws http://www.eyrie.org/~zednenem | of thermodynamics!"