Haskell Platform proposal: Add the vector package

[Roman Leshchinskiy]

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