Except that DiffArrays are slow and expensive in both space and time (compared with strict unboxed arrays). They necesarily hold boxed values so you pay a factor of at least two in space cost (for arrays of Doubles) right off the top, and there's no way you could recover that. I'll admit that they could be useful for something, but I couldn't guess what. In my experience, arrays are always used with strict values, and updates change all the values in an array.
i never quite understood why DiffArrays are so slow at the moment, so perhaps this is a good opportunity to ask for enlightenment on this issue?-) and i don't understand why they should necessarily hold boxed values only: the idea was to hold an efficient full version at the front, and slower differences at the back. what would stop the main version from being unboxed? when i looked into this a while ago, it seemed that the implementation had a lot of overhead, mostly due to avoiding concurrency issues? perhaps the main version could be associated with a specific concurrent haskell thread, so that only other threads would have to pay the management fee, while the common pattern of single-threaded (pardon the pun;) access would be spared that overhead? to make sure that secondary references cannot access the main copy while it is being updated in place, perhaps each thread might need its own main copy (again, that extra price would not be payable in single-threaded practice)? or is that impossible? claus