Proposal: Control.Concurrent.Async
Simon Marlow
marlowsd at gmail.com
Tue Jul 3 14:53:16 CEST 2012
On 18/06/2012 14:56, Ross Paterson wrote:
> On Fri, Jun 15, 2012 at 02:26:51PM +0100, Simon Marlow wrote:
>> On 14/06/2012 16:10, Ross Paterson 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.
>
> The list functions have a similar issue: you have to give them the
> right type when you create them if you want them together in a list.
> Perhaps a convenient interface for the multiplexing part would be
>
> data AsyncF a = forall r. AsyncF (Async r) (r -> a)
>
> instance Functor AsyncF where
> fmap f (AsyncF a k) = AsyncF a (f . k)
>
> waitSTMF :: AsyncF a -> STM (Either SomeException a)
> waitSTMF (AsyncF a k) = fmap (fmap k) (waitSTM a)
Good idea. In fact, I've added a Functor instance for Async itself - it
required a bit of refactoring but didn't add much overhead.
Cheers,
Simon
More information about the Libraries
mailing list