[Haskell-cafe] Re: philosophy of Haskell
conal at conal.net
Sat Aug 14 00:50:57 EDT 2010
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
> > Hi Ertugrul,
> > 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
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.
> nightmare = unsafePerformIO (getWrongWife >>= sex)
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe