[Haskell-cafe] Arguments against an hypothetical Data.ByteString.Generic?
Bas van Dijk
v.dijk.bas at gmail.com
Tue Mar 27 20:38:55 CEST 2012
On 27 March 2012 11:00, Yves Parès <yves.pares at gmail.com> wrote:
> As vector provides a class generalizing all flavours
> (Data.Vector.Generic.Vector), it occurs to me that the same could be done
> for ByteString. Then, packages based on it would have the choice between
> hardcoded and generic, they wouldn't have to duplicate a module to handle
> both strict and lazy versions, as (with the exception of functions for
> communication with C code) they already provide the same API.
> I would be willing to make it, it's a concern I've had in mind for a long
> time, but as I'm pretty sure the idea isn't new, I would very much like to
> know if and what arguments (related to performance maybe ? I don't know...)
> were raised against that.
It's not entirely what you need but are you aware of my
It doesn't (yet) abstract over strict and lazy ByteStrings. But that
would be a nice addition!
In an ideal world we would have a Lazy type family which for each type
of vector would return its lazy version (where the vector is unpacked
in the cons cell). Then we would need your generic API for working
with both lazy and strict vectors.
More information about the Haskell-Cafe