[js8]

I am not sure you can get rid of IO monad. It's how the Haskell programs interact with the outside world, and I think IO is a primitive that you can't build from other things.

But in metaphorical (architectural) sense, yeah, you can probably get rid of it and use different monadic datatypes for different parts of the program that access different pieces in the world.

However, I am not clear how you then combine/serialize those different monads. It seems eventually you will get something like IO monad again. I am not sure but I think there needs to be some master monad going on in all Haskell programs that (potentially) serializes all the actions to the outside world.

[tel]

There has to be an RTS interface. Right now this is "there exists a value called main in the Main module of type IO which the RTS magically understands". This is annoying because it moves so much of IO's reasoning into "RTS Magic".

There are better models of IO (some discussion here http://comonad.com/reader/2011/free-monads-for-less-3/) which essentially boil down to "bidirectional communication channel with a Real Machine" and these can provide a foothold for better semantics. Similar ideas drove the first "IO" based on input and output streams (but handles synchronization the way we need).

There's also chance for other ideas of RTS. For instance, we might embed 99% of Haskell into a real-time RTS and have real world interaction be governed by something like FRP.

[marcosdumay]

The article is about writing your real-word facing code in another monad, and only at an execution layer binding that monad to IO.

[dllthomas]

You can build IO from other things; you can't build other things from IO (because you can't inspect IO).

[steveklabnik]

Haskell had a different system for IO before the IO monad existed, so it's not _strictly_ necessary.

[groovy2shoes]

Yeah, but that system sucked. You essentially sent commands to an external interpreter to do I/O. Simon Peyton Jones calls it "embarassing" in Coders At Work.