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.
_______________________________________________
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
