I've used this a fair amount: e.g. 2D grids going from (-n,-n) to (n,n). This is one of the things I liked about Haskell arrays, in that you _weren't_ limited to the [0,n-1] bounds found in C-based languages (and that annoyed me to no end when I was using them). Even
And to be honest, it's fairly easy to wrap the array functions to specialize them for (0..n-1). It just took me a while to figure out that I would have to make my own array module to stop getting those off-by-one errors.
Meanwhile, they lack basic features like concatenation.
I obviously don't know what you're doing with arrays, but this sounds a bit like using the wrong datatype for the job: if you're concatenating arrays, wouldn't you have to explicitly create or extend one of those arrays to get the contiguous memory (unless you're using a DiffArray)?
Yes, that's also the case for vector, or bytestring, or any of the other array libraries. Concatenating arrays is not a crazy thing to do if it's uncommon and the arrays are not large. You have to copy them in imperative languages too, so it's hardly unique to haskell. Admittedly, I could have used an IntMap but it's a small dense array that's very infrequently changed, and I do mostly iterating forwards and backwards and a plain array seemed simpler than an IntMap with the condition that the keys should be consecutive.
To an extent, I wonder how much of this has been that arrays were considered to be bad in Haskell, so no-one used them and no-one bothered to try and improve the API much (and instead went and created Vector, etc.).
Right, so we have arrays with nicer APIs, it's just that IArray has been kind of left behind. I don't think arrays are bad in haskell, if that were true all those array libraries wouldn't be so popular! They might not be quite the go-to type as in other languages, but they still have their uses.
Any particular reason you used Data.Graph rather than fgl, etc.?
Well... it's built-in... I needed something simple... so I just hit the ghc stdlib doc and searched for "graph". Is this another "left behind" module? And if so... well, maybe it's in the same situation as IArray.
I see there are two possible sources of your "problems" here:
1. The underlying data structure (index types and bounds, etc.) 2. The API
You mainly seem to have an issue with the API itself. My guess is that the API for array hasn't changed much because it was already there and a boot library (so incremental changes, etc.) whereas when vector, etc. was being written the opportunity was being taken to create an API better suited for the task, taking into account people's usage of array.
Right, it's hard to dislike the underlying data structure, arrays are about as simple as you can get :) My guess was the same as yours, i.e. that it's been sort of neglected but it's a bootlib and H98 so nothing can happen to it quickly. I can't realistically suggest a course of action here, other than "gosh someone should update these modules" to which everyone is likely to say "yes, it would be nice if you did that" :) Or maybe in 10 years vector will be mature and standard and the old Array stuff can be deprecated and removed. So that's why this was more of a little rant than actual constructive comment. Maybe at the least I could submit a patch to the IArray haddock saying "there are other array interfaces out there on hackage if you're looking for the 'default array' and this one isn't doing it for you". Maybe the same with Data.Graph and fgl, if that's so much nicer. But then, you know, it feels strange for a stdlib to come with such disclaimers :)