[Haskell-cafe] Re: :t main

[David Menendez]

Scherrer, Chad writes:

> > From: Cale Gibbard [mailto:cgibbard at 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 <zednenem at psualum.com> | "In this house, we obey the laws
<http://www.eyrie.org/~zednenem>      |        of thermodynamics!"