IO vs Task vs Future

[Ken Scambler]

From reading the docs I see that Tasks build on Futures, adding error-handling functionality.  Is that the only difference between them that I should care about? 

What is the difference in intent between IO and Task -- when would I choose one over the other?

I seem to remember comments indicating that Task should generally preferred over IO, but I can't remember where I saw that now.  AFAICT both are trampolined, but Task is asynchronous, leaving perhaps not much reason to choose IO other than sidestepping the concurrency machinery.

Cheers,
Ken

[Robert Norris]

Hi Ken,

From where I sit the trend seems to be to use Task for IO, and if you simply swap IO.apply with Task.delay and .unsafePerformIO with .run your program should do the same thing; and now you have the ability to add async and all that. However there's a bunch of nice stuff you get with IO that doesn't exist (yet) for Task:

• IO has useful exception-handling combinators
• IO has basic console primitives (putStrLn, etc.)
• You have MonadIO and MonadCatchIO, for lifting IO values when working with transformers
• The mutable cell stuff (IORef, Atomic, Chan, MVar) all work in terms of IO
• There's some resource safety stuff (Resource, which is very basic, and RegionT, which I have never figured out)

There was talk replacing all of this (Future, Task, IO) with a new implementation a while back, and it seems like people have been waiting on that rather than trying to beef up or rework it in-place. I would be interested if anyone has a status update on this.

rob 

--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalaz+un...@googlegroups.com.
To post to this group, send email to sca...@googlegroups.com.
Visit this group at http://groups.google.com/group/scalaz.
For more options, visit https://groups.google.com/d/optout.

[Tony Morris]

Is it really true that you can substitute one for the other without a significant difference in program semantics? I must be missing something.

[Paul Chiusano]

Yes that is true. If anyone can construct an example where that is not the case I would be very interested to see it.

If you formulate Task and IO as free monads, Task just adds an async instruction. If you don't use it then the behavior is the same. Task and IO in scalaz have a bunch of IMO confusing and irrelevant differences and details. (Like that IO is formulated as an ST monad instead of a free monad)

I'd still like to see a better type that unifies Task and IO and fixes all the stuff that is dumb about Task. Runar was working on this at one point and I think some other folks have as well.

Paul

[Alois Cochard]

Hi folks,

I have experimented with an alternative IO RTS system here:

https://github.com/aloiscochard/matterhorn

(fwiw, the instructions are here: https://github.com/aloiscochard/matterhorn/blob/master/core/src/main/scala/RTS.scala#L74-L82, and the interpreter here: https://github.com/aloiscochard/matterhorn/blob/master/core/src/main/scala/rts/Interpreter.scala)

Which seems to solve the problem nicely to me, but I'm not confident enough to be sure it's really a good idea ;-}

Cheers

Λ\ois

http://twitter.com/aloiscochard

http://github.com/aloiscochard

[Ken Scambler]

Not to fill up the list with happy-talk, but thanks everyone -- the responses were both useful and interesting. Cheers.