What's the benefit of scalaz.concurrent.Future, in comparison to scalaz.ContT[Trampoline, Unit, ?]

Question

I was looking for a data type for asynchronous operations.

I found that scalaz.ContT[Trampoline, Unit, ?] supports all features in scalaz.concurrent.Future, in addition of BindRec.

Though, there are more utilities for scalaz.concurrent.Future than scalaz.ContT[Trampoline, Unit, ?], e.g. an Applicative instance runs Futures in parallel.

I thought those utilities can be implemented for ContT[Trampoline, Unit, ?] as well.

Why did the author create a new Future-based scalaz-concurrent library, instead of reusing ContT?

Answer 1

At the risk of being facetious, one key benefit is that Future is a named concept that lots of people will recognise and understand, for example it has its own wikipedia page.

I don't recognise the ContT type which you say is equivalent. I tried to find it in the scalaz docs, but it is listed there with no explanation. Where can I read more about this, and how do you know it is equivalent to a Future?

You say that "an Applicative instance runs Futures in parallel"; would multiple ContT operations not be run in parallel? That is a key feature of Futures, and might be an answer your question.

UPDATE:

I see now that ContT is an implementation of continuation passing style, and that scalaz.ContT[Trampoline, Unit, ?] is a special case of a continuation passing function that may be isomorphic to Future, if certain external assumptions hold.

I think that the answer to your question is the same reasons that many other special cases are given prominence when they could perhaps be thought of as one case of a more general structure:

• It is easier to discuss and easier to name
• It is more efficient, as the implementation can take advantage of some special cases that may not hold in the general structure
• It is easier to reason about, for example here we can be sure that Futures are executed in parallel, whereas we don't know that about continuation passing functions in general. (Of course, it is possible to execute Futures in sequence, as is done in some test frameworks, but that would not be considered a conventional implementation of Future)
• It is a useful concept and it benefits programmers to highlight it and make it easily accessible