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>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
