Re: FiniteMap in Hugs
"Sigbjorn Finne (Intl Vendor)" wrote: > The reason why FiniteMap and friends aren't included in > the Hugs/GHC libraries, is that we're waiting for the > design of a Collections library to be finalised (and > released). We've been waiting for 9 months for that to > happen, so hopefully something will materialise on that > front soon... Sorry, that's me. I've been pretty much at a standstill for most of those 9 months fighting Makefile problems with GHC. But Ralf Hinze finally took care of this for me recently, and there should be a release soon! Chris
Re: RFC: Overloaded arrays
Simon Marlow wrote: > class HasBounds a => IArray a e where > (!) :: Ix ix => a ix e -> ix -> e > array :: Ix ix => (ix,ix) -> [(ix,e)] -> a ix e > > class (Monad m, HasBounds a) => MArray a e m where > read:: Ix ix => a ix e -> ix -> m e > write :: Ix ix => a ix e -> ix -> e -> m () > marray :: Ix ix => (ix,ix) -> m (a ix e) My main comment is please don't ignore a simple update operation on immutable arrays, with a type something like update :: Ix ix => a ix e -> ix -> e -> a ix e I don't care about the name but I do care about the functionality. I'm perfectly happy with the naive, dirt simple, O(n) implementation that copies the whole array and makes the update in the copy. Yes, there is the // operation, but 95% of the time I just want to update a single element. Most functional languages leave this operation out, I presume because the feeling is that it is so expensive that no one would ever want to call it. But I've found myself wanting it lots of times, usually with very short arrays (say, length 4 or 8). Chris
Re: RFC: Overloaded arrays
Simon Marlow wrote: > Actually, I'm slightly concerned about your use of small arrays: the static > (one-off) cost of allocating an array is quite high compared to eg. tuples > or records. Are arrays the only solution here? You're right of course that arrays are quite expensive, but it is not clear to me whether this is an inherent property of arrays or an artifact of the current implementation. At least part of it is inherent, because of the extremely general nature of Haskell's arrays (use of Ix, arbitrary bounds). I've never understood the advantages of these arrays over a more primitive mechanism (indexed by integers starting at 0), with the fancier arrays built on top of the primitive arrays in a library. But this is not a battle I'm prepared to fight right now! As to whether arrays are the only solution, well, no. Tuples are out because the size is not necessarily known in advance. Or even if the size is known, you may expect it to change several times during development. Lists are a posibility, but, when I say "short, that might be as high as maybe 256. Some tree-like implementation of arrays, such as Braun trees would not be unreasonable. But arrays seem like the most natural choice. It would be a shame it steer programmers away from arrays just because they are disproportionately expensive. Chris