Proposal: Control.Concurrent.Async

Conrad Parker conrad at metadecks.org
Tue Jun 19 03:06:13 CEST 2012


On 16 June 2012 13:26, wren ng thornton <wren at freegeek.org> wrote:
> On 6/15/12 9:31 AM, Simon Marlow wrote:
>>
>> On 14/06/2012 22:54, Lauri Alanko wrote:
>>>
>>> Quoting "Simon Marlow" <marlowsd at gmail.com>:
>>>>
>>>> Naming is obviously up for discussion too.
>>>
>>>
>>> I feel that "Async" is a bit too generic and doesn't very precisely
>>> characterize this particular construct. How about "Future", as similar
>>> things are called in e.g. Alice
>>> <http://www.ps.uni-saarland.de/alice/manual/futures.html> and Java
>>>
>>> <http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/FutureTask.html>?
>>>
>>
>> "Future" evokes notions of parallelism for me, rather than concurrency.
>> I think the term is more often used in a parallel setting.
>>
>> There's a precedent for using 'async' for concurrency: see the new C#
>> and F# async extensions:
>>
>> http://msdn.microsoft.com/en-us/library/hh191443%28v=vs.110%29.aspx
>>
>> But naming is hard, and if everyone wanted to use "future" instead I
>> wouldn't object very strongly.
>
>
> I object to "future" as using an overly general term for one very particular
> instantiation of it. At the very least it must be qualified as "concurrent
> future". Though I'm not particularly opposed to "async"; and if there's
> precedent, then all the better.

"future" also seems to me to be more about waiting for the result
value, not about doing something concurrently. Then again I work on a
codebase which involves financial futures contracts, which also
involve waiting for a return value ...

Conrad.



More information about the Libraries mailing list