On Fri, Apr 20, 2007 at 08:33:41PM +0100, Andrew Coppin wrote:

...

Indeed, unboxed arrays are much nicer, but the whole Array batch of the standard library is pretty useless, in my experience. You can roll your own relatively easily using ForeignPtr, similar to Data.ByteString, but that's a bit of a pain.

There is no *way* I'm playing with C. The entire point of Haskell is to allow mankind to eradicate C forever. :-)

ForeignPtr doesn't have anything to do with C, it's just the data structure you need to use if you want to write your own unboxed array.

I was more interested in seeing people's comments about the program changes. For example, why would an in-place update be slower than lots of dynamically-allocated lists? That's totally counterintuitive. Also, is there any way in hell I can make the program stricter without mutilating the entire thing to use unboxed arrays? I couldn't figure out a way to do this. (Would be nice if there was a compiler switch to just turn off all laziness - but as far as I can tell, there isn't.)

The in-place update (without boxing) still dynamically allocates thunks, which are similar in cost to cons cells (for some definition of similar). Unboxed arrays are exactly what you want--except that the UArray type is limited, which is why I recommended rolling your own. Hopefully the PArr package will help reduce the pain of using arrays. In any case, in my opinion Haskell desperately needs more strict data types, as strict types can go a long way towards eliminating all sorts of pain. I remember once going through all sorts of pain trying to avoid stack overflows when using Data.Map to compute a histogram, which all would have been avoided if there were a strict version of Data.Map (or even just strict functions on the lazy Data.Map). I don't think eliminating all laziness is a good idea, but (optional) strict datatypes most certainly are, as they can go a very long ways towards eliminating memory leaks. -- David Roundy Department of Physics Oregon State University