Proposal: Control.Concurrent.Async

Simon Marlow marlowsd at gmail.com
Fri Jun 15 15:56:37 CEST 2012


On 15/06/2012 14:43, Sjoerd Visscher wrote:
>> > An alternative, equivalent interface for waitEither and friends
>> would be
>> >
>> > waitEither :: Async a -> Async a -> IO (Either SomeException a)
>> > waitEitherThrow :: Async a -> Async a -> IO a
>> >
>> > This might be conceptually simpler, leaving it to the user to decide
>> > whether to mark the results with Left/Right, or something else, or
>> not. > Similarly the Async now returned by waitAny and friends could
>> be left
>> > to the user. That would leave the two sets of functions more in line.
>> I liked this suggestion at first, but later concluded that it isn't as
>> nice. The problem is that to convert an 'Async a' to an 'Async (Either
>> a b)' has to be done when you create the Async in the first place, or
>> else you have to write some STM code to lift the result. If you're
>> writing some STM code anyway, then there's little point in using
>> waitEither.
>
> What's the problem with converting when you create the Async?
>
>> withAsync (Left <$> getUrl url1) $ a1 -> do
>> withAsync (Right <$> getUrl url2) $ a2 -> do
>>   waitEither a1 a2
>
> This seems more explicit to me. And if you really don't care which of
> the results you want, they'll probably have the same type anyway.

It forces you to decide how the Async is going to be used when it is 
created, which would make it difficult to have an abstract interface 
between the consumer and the producer.  For example, suppose you need to 
use the Async in multiple different places with different waitEithers or 
waitAnys, then it would be inconvenient.

Cheers,
	Simon



More information about the Libraries mailing list