[Haskell-cafe] uvector and the stream interface

[stefan kersten]

On 14.07.2008, at 18:42, Jules Bean wrote:
>> It would be helpful to see the programs people are writing with  
>> uvector,
>> so I can polish up the API some more :)
>
> It would also be helpful to have someone explain why we have:
>
> Ptr a
> ByteString
> IOUArray
> IOCArray
> Data.Storable.StorableArray
> UArr
>
> Of course, I know the answers to some of those questions,  
> ByteString is obviously less polymorphic than all the others there,  
> and Ptr a doesn't contain size information. But it seems we have a  
> rapidly bifurcating profusion of 'typed interfaces to chunks of  
> memory' with no obvious consistency to their naming scheme and I  
> think it's starting to get confusing...

maybe it would be useful to look at (1) what's expected in terms of  
the underlying array implementation and (2) in terms of array access.

(1) some things that come to mind:

* ghc heap or system heap (can the garbage collector move memory  
during calls to C?)
* access to a Ptr for interfacing to external libraries (possible  
with UArr?)
* alignment (most SIMD instruction sets require 16 byte aligned data)
* mutability
* strict vs (partially) lazy

(2) personally i much prefer the list-like interface provided by the  
stream-fusion powered libraries (ndp, uvector, vector). can't the  
stream-fusion framework and correspondingly the vector interface be  
separated from the memory representation, provided a particular  
concrete representation comes up with a stream/unstream pair? then it  
would be easy to swap out the underlying representation according to  
the required characteristics.

<sk>