[Haskell-cafe] Data.IArray rant

[Evan Laforge]

> 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 :)