[Haskell-cafe] Referential Transparency and Monads

Jonathan Cast jonathanccast at fastmail.fm
Thu Apr 9 22:30:30 EDT 2009

On Thu, 2009-04-09 at 21:57 -0400, Brandon S. Allbery KF8NH wrote:
> On 2009 Apr 9, at 16:09, Luke Palmer wrote:
> > On Thu, Apr 9, 2009 at 1:33 PM, Miguel Mitrofanov
> > <miguelimo38 at yandex.ru> wrote:
> >                 I'm not sure what you mean by that, but semantically
> >                 IO is definitely
> >                 *not* a state monad.  Under any circumstances or any
> >                 set of assumptions.
> >         
> >         
> >         Ehm? Why not?
> > 
> > Mainly forkIO.  There may be other reasons.
> > 
> I thought I had excluded that stuff to simplify the question; the fact
> that IO is Haskell's toxic waste dump is more or less irrelevant to
> the core concept.

Well, the `core concept' of IO includes the concept of a user who's
watching and interacting with your program as it runs, no?

Say I know that a file named `/my_file' exists and is readable and
writeable and etc.  Now consider the program

     s <- readFile "/my_file"
     writeFile "/my_file" "Hello, world!\n"
     threadDelay 10000 -- If you don't like threadDelay, just substitute forcing
                       -- an expensive thunk here
     writeFile "/my_file" s

As a function from initial state to final state, this program is just
the identity; but surely this program should be considered different
than just

  threadDelay 10000

.  To give a meaningful semantics to IO, you have to consider the
intermediate state(s) the system goes through, where a state monad
denotation for IO would discard them.


More information about the Haskell-Cafe mailing list