[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
[@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).