Haskell Platform proposal: Add the vector package

[Henning Thielemann]

On Tue, 19 Jun 2012, Roman Leshchinskiy wrote:

> On 18/06/2012, at 23:16, Henning Thielemann wrote:
>
>> On Mon, 18 Jun 2012, Roman Leshchinskiy wrote:
>>
>>> There are type families, rank-n types, unboxed types and other goodies deep in the guts of vector so the Storable part is very much GHC-specific. To be honest, I don't think being portable is feasible for high-performance code at the moment, the language standard simply doesn't have enough tools for this. Which is a shame, really.
>>
>> I am not mainly interested in the efficient implementation. I am completely ok with having the definition of (Vector a) in a separate package, such that it can be used by vector (GHC only) and storablevector (portable).
>

> By Vector a you mean just the data type, not the type classes, right?

yes

> What would the package contain apart from the type definition?

If the implementation of Vector functions requires GHC extensions then the 
pure Vector data type definition would be the only definition. However, if 
Vector is defined as it is and these direct manipulations of ForeignPtr 
are not portable, then there is even no benefit in putting the Vector 
definition in a separate package. We should then leave the 'vector' and 
the 'storablevector' packages as they are and have to convert explicitly 
between these types.

>>> Storable should *really* live in ST but it's too late for that now.
>>
>> How would this prevent from broken pointer arithmetic?
>
> It wouldn't but it would rule out this:
>
> data T = T
>
> class Storable T where
>  peek p = do
>    print "Peeking"
>    spam ghcBugTracker
>    return T


I see. But how would I define an ST-Storable instance for a new type, say 
LLVM.Vector (the CPU vector type in 'llvm') without unsafeIOtoST? I could 
still lift the 'spam' command into ST. However, ST might make people think 
more thoroughly whether the lifted operations are appropriate for ST.