On Sat, Aug 14, 2010 at 9:27 AM, Ertugrul Soeylemez
<es@ertes.de> wrote:
Conal Elliott <
conal@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
>
> Hi Ertugrul,
>
> This state monad model does not really work for IO, since it fails to
> capture IO's concurrency (with non-deterministic interleaving).
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 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.)
Other approaches like
functional reactive programming may be better at capturing these things,
particularly the interactions between concurrent threads, at least for
specific applications.
> So, maybe these models are models of something other (and much less
> expressive) than Haskell's IO. Which re-raises Jerzy's question.
Haskell's IO is flexible at the cost of being quite low level. I think
to capture things like concurrency properly and explicitly you need a
richer sublanguage, maybe something based on the pi calculus.