[Haskell-cafe] Array, Vector, Bytestring

Artyom Kazak yom at artyom.me
Tue Jun 4 01:32:58 CEST 2013

silvio <silvio.frischi at gmail.com> писал(а) в своём письме Mon, 03 Jun 2013  
22:16:08 +0300:

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

More information about the Haskell-Cafe mailing list