[Popping up to the big-picture question for a moment, from the previous thread on Vector CAS.]

Given that a lot of people are really advertising Haskell on the parallel/concurrent front, it seems like we should be committed as a community to making our basic libraries support parallel/concurrent use cases effectively.  This will necessarily mean touching some core libraries (container, vector...).

The two things that have come up for me recently are (1) CAS/RMW on [unboxed] Vectors and a general notion of balanced-splitting for tree-based structures (Map,Set).  But I'm sure there are others!

Is any one else invested in getting this kind of thing moving?  It would be great to have a partner.  I can commit a small amount of cycles, but I don't have lots of bandwidth for non-research infrastructure work presently.  Edward, is any of this useful to you?  

In many of these cases it seems like the main problem is not a technical one, but the social one of consensus building (and fighting excessive "stop energy" if it appears).  Edward, as chair of the core libraries committee, maybe you could help with this?

Cheers,
  -Ryan


On Thu, Nov 21, 2013 at 10:25 AM, Ryan Newton <rrnewton@gmail.com> wrote:
[@Aleksey] Very good point!  I'd missed that vector does the SOA->AOS business too.  (I thought that was just Repa & Accelerate.)

In any case, an unboxed vector of tuples can't actually support atomic CAS anyway, so not supporting it is inevitable.
   It does mean that exposeMutableByteArray can't be a method of the Unbox class.  It would need to be another class capturing the subset of vector types that are "Atomic" (support concurrent/atomic memory ops).