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

[Julien Fischer]

Hi,

Here are some addtional comments.  Can you please post a revised diff
after you have addressed Peter's comments and these.

On Tue, 7 Oct 2014, Peter Wang wrote:

> On Mon,  6 Oct 2014 16:30:39 +1100, Paul Bone <paul at bone.id.au> wrote:
>> Branches: master.
>>
>> For review by anyone.
>>
>> ---
>>
>> Add future datatype for concurrent and parallel programming
>>
>> library/library.m:
>> library/thread.future.m:
>> library/thread.m:
>>     Add new future standard library module.
>>
>> NEWS:
>>     Announce the new addition.
>>
>> library/thread.semaphore.m:
>>     Add an impure interface to thread.semaphore.m.  Semaphores are used to
>>     implement our other concurrency primatives and an impure interface can
>>     often be useful to implement things such as futures, which don't require
>>     IO state threading.
>>
>> benchmarks/progs/mandelbrot/mandelbrot.m:
>> benchmarks/progs/mandelbrot/bench.sh:
>>     Add future example to mandelbrot benchmark.
>
>> diff --git a/library/thread.future.m b/library/thread.future.m
>> new file mode 100644
>> index 0000000..45d05dd
>> --- /dev/null
>> +++ b/library/thread.future.m
>> @@ -0,0 +1,238 @@
>> +%-----------------------------------------------------------------------------%
>> +% 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".

>
>> +% styles of futures.  A future can be set exactly once, but can be read a
>> +% number of times, this allows the implementor to use a more efficient
>> +% algorithm than for mvars.
>
> Two sentences.
>
>> +%
>> +% 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.

Cheers,
Julien.