[Haskell-cafe] Re: philosophy of Haskell

[Ertugrul Soeylemez]

"Patai Gergely" <patai_gergely at fastmail.fm> wrote:

> > I don't agree.  A concurrent change is the effect of an IO action,
> > not of the thread.  For example if a concurrent thread writes to an
> > MVar, then that change becomes the effect of the next takeMVar,
> > which gets executed.  If a concurrent thread changes a file on disk,
> > then that changing becomes the effect of the next readFile, which
> > reads the changed file.
>
> But that's exactly what the model cannot handle. Look at the following
> snippet again:
>
> >  let (x, world1) = getLine world0
> >      world2 = print (x+1) world1
>
> This clearly says that the world returned by getLine and the world
> consumed by print is the same one, since the state monad model is
> pure, therefore world1 is immutable. However, this is not true, since
> someone else could have modified it in the meantime. The state monad
> can only describe a single thread, but that's a non-existent situation
> in the case of I/O, since the world keeps changing outside the program
> even if the program itself is single-threaded.

No.  As you say the world1 value is immutable, but that's not
contradictory.  If between 'getLine' and 'print' something was done by a
concurrent thread, then that change to the world is captured by 'print'.

See for example the following code:

  var <- newEmptyMVar
  forkIO $ threadDelay 1000000 >> putMVar var 15
  takeMVar var >>= print

Let's translate it:

  \world0 ->
  let (var, world1) = newEmptyMVar world0
      world2 = (forkIO $ threadDelay 1000000 >> putMVar var 15) world1
      (result, world3) = takeMVar var world2
  in print result world3

The subthread has the following code:

  \world0 ->
  let world1 = threadDelay 1000000 world0
  in putMVar var 15 world1

In the main thread the delay of one second and the change to the MVar is
/not/ an effect of another thread.  There is no notion of threads at
all.  It's a side effect of takeMVar.  The thread launched by forkIO
becomes part of the opaque world variable, which captures everything.
Otherwise we would have to say that the state monad model doesn't
capture user input either, because conceptually there is no difference
between a user typing something and a concurrent thread writing to
stdin.

IO has no specific notion for threads.  Threads are just side effects.
Things caused by threads is captured by normal IO actions like getLine
and takeMVar.  That's not a flaw of the interpretation as a state monad.
That's a flaw of the IO monad itself.


Greets,
Ertugrul


-- 
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/