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

[Paul Bone]

On Thu, Oct 09, 2014 at 01:43:06PM +1100, Julien Fischer wrote:
>
>
> On Thu, 9 Oct 2014, Peter Wang wrote:
>
>> On Thu, 9 Oct 2014 13:32:58 +1100 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>>>>>
>>>>> impure_init needs to be (1) a function and (2) defined in the public interface,
>>>>> since users require a way of initialising semaphore valued mutables.
>>>>
>>>> Why?  If the rest of the semaphore library was pure I/O code was this ever
>>>> used outside of the standard library?
>>>
>>> The version history is a bit confused because these modules were
>>> originally moved out of extras directory back when we were using CVS.
>>> It looks as though the purity of semaphore.new was originally incorrect
>>> and later corrected by being made impure.  (At some point we changed
>>> all the 'new' predicates to 'init'.)
>>>
>>>> I'm not if we do need to provide such a function, at least the
>>>> deprecation will allow people to continue to use this and we can find
>>>> out if it causes a problem for anyone.
>>>
>>> I think mutable initialisation is a legitmate reason for this to be
>>> provided.
>>
>> Bug #223
>
> Ok, so the _function_ impure_init still needs to be public
>
> For consistency, the function mvar.impure_init should be introduced.
>

Thanks guys, I've made the changes from the last few e-mails and committed
the result.


-- 
Paul Bone