silvio
Hi everyone,
Every time I want to use an array in Haskell, I find myself having to look up in the doc how they are used, which exactly are the modules I have to import ... and I am a bit tired of staring at type signatures for 10 minutes to figure out how these arrays work every time I use them (It's even worse when you have to write the signatures). I wonder how other people perceive this issue and what possible solutions could be.
Recently I’ve started to perceive this issue as “hooray, we have lenses now, a generic interface for all the different messy stuff we have”. But yes, the inability to have One Common API for All Data Structures is bothering me as well.
Why do we need so many different implementations of the same thing? In the ghc libraries alone we have a vector, array and bytestring package all of which do the same thing, as demonstrated for instance by the vector-bytestring package. To make matters worse, the haskell 2010 standard has includes a watered down version of array.
Indeed. What we need is `text` for strings (and stop using `bytestring`) and reworked `vector` for arrays (with added code from `StorableVector` — basically a lazy ByteString-like chunked array).
# Index
I don't really see a reason for having an index of a type other than Int and that starts somewhere else than at 0.
It’s a bad idea. I, for one, don’t really see how writing `Vector (Vector (Vector Int))` can be considered even remotely satisfying by anyone. And if you’re considering 3D arrays “a corner case”, then I’m afraid I can’t agree with you. Also, arrays which allow negative indexing can save a lot of headache and prevent mistakes which generally occur when a programmer is forced to constantly keep in mind that index 2000 is actually 0 and 0 is −2000.
# Storable vs Unboxed
Is there really a difference between Storable and Unboxed arrays and if so can't this be fixed in the complier rather than having to expose this problem to the programmer?
Storable seems to be mainly for marshalling, and most people who need it are (probably) library writers. I don’t know for sure, though, but it doesn’t appear to be a big issue.
# ST s vs IO
This is probably the hardest to resolve issue. The easiest solution is probably to just have a module for each of them as in the array package. I find the PrimState a bit complicated and circuitous.
The ideal solution would be to have
type IO a = ST RealWorld# a
in the next haskell standard.
Sure, except that IO is actually *not* ST+Realworld, and only happens to be implemented like that in GHC (not in JHC, for instance). It has been discussed before: http://haskell.1045720.n5.nabble.com/IO-ST-RealWorld-td3190075.html . (Not to mention people attempting to rewrite RealWorld# values and create havoc and fire missiles everywhere expecting them to disappear the very moment they smile knowingly and `put` the original RealWorld# back.)