[Haskell-cafe] Re: philosophy of Haskell

[Ertugrul Soeylemez]

Conal Elliott <conal at conal.net> wrote:

> On Sat, Aug 14, 2010 at 9:27 AM, Ertugrul Soeylemez <es at ertes.de> wrote:
>
> > Conal Elliott <conal at conal.net> wrote:
> >
> > > > There are various models.  One (the state monad model) of them
> > > > would desugar this to:
> > > >
> > > >  \world0 ->
> > > >  let (x, world1) = getLine world0
> > > >      world2 = print (x+1) world1
> > > >      world3 = print (x+2) world2
> > > >  in world3
> > >
> > > This state monad model does not really work for IO, since it fails
> > > to capture IO's concurrency (with non-deterministic interleaving).
> >
> > Well, it does capture concurrency and FFI, but it has no explicit
> > notion for it.  In other words, concurrent threads and FFI calls are
> > effects like everything else, so the forkIO function just changes
> > the world state implicitly and that's it.
>
> Consider that IO's concurrency means that something else can happen
> between printing x+1 and printing x+2, so that x+2 is *not* printed in
> world2, but rather in a world influenced outside of this thread.
> Similarly, x+1 might not be printed in world1, and the getLine might
> not be executed in world0.  So World -> (a, World) is *not* expressive
> enough to explain Haskell-IO-style concurrency.
>
> Do you see what I mean?

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.

As said, the state monad model captures concurrency, but has no explicit
notion for it.  It captures it as an effect just like every other.


> > > I don't know whether/how the "EDSL model" you mention addresses
> > > concurrency or FFI.
> >
> > Just like the state monad model.  This is not a weakness of the
> > interpretation, but of the IO monad itself, because it is quite a
> > raw and straightforward language for doing I/O.
>
> And the IO monad is what Jerzy asked about.  I'm pointing out that the
> state monad does not capture concurrency, and the "EDSL model" does
> not capture FFI.  (Really, it depends which "EDSL model".  I haven't
> seen one that can capture FFI.  And maybe not concurrency either.)

The EDSL model is just an imperative language inside of Haskell.  It
captures thread launching as an action and concurrent changes as
actions.  Just as well it does capture FFI calls as actions, and so on.

Maybe you have some notion of "capturing" other than "being able to
express".  Maybe by "capturing" you mean being able to express the
particular concept/construct in the type system.  But then the IO monad
doesn't even capture writing to a file handle.  Or maybe you're talking
about elegance.  I don't really know.


Greets,
Ertugrul


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