std.parallelism changes done

[spir]

On 03/24/2011 05:32 AM, dsimcha wrote:
> One thing Andrei mentioned that I'm really not sure about is what to do with
> TaskPool.join().  My example for it is still terrible, because I think it's an
> evolutionary artifact.  It was useful in earlier designs that were never
> released and didn't have high-level data parallelism primitives.  I never use
> it, don't have any good use cases for it and would be inclined to remove it
> entirely.  Andrei seems to have some good use cases in mind, but he has not
> detailed any that I believe are reasonably implementable and I'm not sure
> whether they could be solved better using the higher-level data parallelism
> primitives.

If I may have a suggestion: just let it aside. Instead of piling up features, 
just have the core available, and let actual needs show up in real life.
An exception may be when a given potential feature would require major 
re-design. Then, better to anticipate with a design that could accomodate it. 
Else, better to apply the famous phrase that design is finished when nothing is 
left to remove. Very true (even more in PL design where it's about impossible 
to remove a feature once released, as an after-thought).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com