Re: taskbuilder status

[Mauricio Scheffer]

Hi Dave,

I think the current implementation is already usable. We can later look into writing a separate monad that is explicitly delayed, as I said this could buy us composability at the price of memory and performance due to the thunks. Then again, perhaps YAGNI applies here.

Operations like >>., kleisli, lift2, etc can probably be expressed in terms of Task primitives instead of the generic monadic implementations which could be slightly faster.

Other operations like bind and map are already implemented in terms of Task primitives, I don't see how they could be improved...

We also need more tests.

Ryan also suggested a function that runs a Task and returns a Choice between the result and an exception (not sure how cancellation is handled here). He also suggested a 'choose' or <|> operator, returning the first of two Tasks that doesn't fail.

Cheers.

Mauricio

On Tue, Apr 3, 2012 at 2:24 PM, Dave Thomas <kukulca...@gmail.com> wrote:

I forgot it returned the antecedent task, I might have an optimisation, Ill fork your branch and see if I can get some timings...

D.

On 3 April 2012 17:35, Dave Thomas <kukulca...@gmail.com> wrote:

I left a message on the initial commit of the taskbuilder, I thought I would just drop it here...

Why do you need a Task.Unwrap at the end of the Bind?

Hopefully I should be able to help out with some of this is needed, we could do with aligning the fast path options in .Net 4.5 for zero or close to zero allocations...

Cheers

D.