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.