[m-rev.] for review: Add future datatype for concurrent and parallel programming

[Paul Bone]

On Tue, Oct 07, 2014 at 02:47:54PM +1100, Julien Fischer wrote:
>
> Hi,
>
> Here are some addtional comments.  Can you please post a revised diff
> after you have addressed Peter's comments and these.
>

No problem, I'll post it shortly.

>>> +% vim: ft=mercury ts=4 sw=4 et
>>> +%-----------------------------------------------------------------------------%
>>> +% Copyright (C) 2014 The Mercury Team.
>>> +% This file may only be copied under the terms of the GNU Library General
>>> +% Public License - see the file COPYING.LIB in the Mercury distribution.
>>> +%-----------------------------------------------------------------------------%
>>> +%
>>> +% File: thread.future.m.
>>> +% Authors: pbone.
>>> +% Stability: low.
>>> +%
>>> +% This module defines a future datatype for parallel and concurrent
>>> +% programming.
>
>
> s/datatype/data type/
>
>>> +%
>>> +% A future represents a value that may or may-not exist yet.  There are two
>>
>> may not
>
> Also, it is a bit redundant to say "may or may not".
>

I've revised this to "...that might not exist yet."

>>> +%
>>> +% There are two ways to use futures.  The first is to create a future,
>>> +% and supply it's value as separate steps.  This is the most flexible way
>>> +% but requires use of the IO state:
>>
>> its
>
> In the documentation it is: I/O state, not IO state.
>
> More generally, I don't like the fact that the names of the the pure and
> impure versions of the semaphore predicates are overloaded.  Also, I
> think you should separate out the impure interface so that it is
> documented in a section of its own, below the pure one.
>

In that case I suggest a hidden interface section.


-- 
Paul Bone