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?
> However, I have just looked into Vector.Storable and it looks like
>
> data Vector a = Vector Int (ForeignPtr a)
>
> I thought it was
>
> data Vector a = Vector {len :: Int, allocated :: ForeignPtr a, start :: Ptr
> a}
The ForeignPtr already stores an Addr#:
data ForeignPtr a = ForeignPtr Addr# ForeignPtrContents
I just manipulate it directly which saves a pointer per vector. This might not
seem like a big deal but sometimes this pointer will be threaded through a loop
clobbering registers which *is* a big deal. Simon Marlow says that there is no
requirement that the Addr# in the ForeignPtr must point to the start of the
block.
I would make this more explicit by manually unpacking the ForeignPtr but alas,
ForeignPtrContents (the actual type name) isn't exported from GHC.ForeignPtr so
I can't.
Incidentally, this is another portability issue.
>> FWIW, Storable vectors are fundamentally broken, anyway, since a Storable
>> instance can perform arbitrary I/O in its methods but a pure vector based on
>> Storable will necessarily have to unsafePerformIO these operations.
>
> That's unfortunately true.
>
>> 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
Which, unfortunately, is a perfectly valid implementation of peek.
Roman
_______________________________________________
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
