Haskell Platform proposal: Add the vector package
lemming at henning-thielemann.de
Tue Jun 19 10:24:48 CEST 2012
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?
> 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.
More information about the Libraries