[Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0

[Bas van Dijk]

On 17 October 2011 13:12, Christian Maeder <Christian.Maeder at dfki.de> wrote:
> Am 17.10.2011 12:14, schrieb Bas van Dijk:
>>
>> On 17 October 2011 10:18, Christian Maeder<Christian.Maeder at dfki.de>
>>  wrote:
>>>
>>> I think the cleanest solution (just from a theoretical point of view) is
>>> to
>>> use a newtype for your byte strings.
>>>
>>> - it should have the same performance
>>> - allows to make ByteString really abstract when hiding the newtype
>>> constructor
>>
>> But what would a newtype ByteString = ByteString (Vector Word8)
>> abstract over? What's there to hide? Vectors are already abstract so
>> users can't mess with their internals.
>
> Maybe some of the functions that start with "unsafe"?

But to keep compatible with bytestring's Data.ByteString.Unsafe, I
have to export the unsafe functions anyway.

I do think we should provide a Data.Vector.Storable.Safe module which
only exports the safe interface and mark it Trustworthy using the new
Safe Haskell language extensions.

Roman: any reason why only storable vectors are missing a Safe module?
I could add one this evening, if you like?

And should we also export Unsafe modules like how it's done in the base library?

> http://hackage.haskell.org/packages/archive/vector/0.9/doc/html/Data-Vector-Storable.html#t:Vector
>
>>> - is portable and supplies control over all other instances (not just
>>> Show)
>>
>> What other instances (besides Show) should have different semantics
>> than those of Vector?
>
> instance Read (and maybe the vector package will evolve further).
>
>>> I'm not sure if one could make really bad thinks to your ByteString by
>>> using
>>> the Vector interface, but one would want to disallow vector operations
>>> just
>>> for compatible with other byte strings.
>>
>> My idea is that when vector-bytestring is as fast as bytestring, it
>> can replace it. When that happens it doesn't matter if users use the
>> vector interface. I would even recommend it over using the bytestring
>> interface so that bytestring can eventually be deprecated in favor of
>> vector.
>
> So your package basically supports an unfortunate mix of bytestring and
> vector functions?

No, vector-bytestring exports the same API as bytestring (except for
the Show and Read instances which will hopefully be fixed in a new
vector release).

> How about proposing a better bytestring interface (if it
> should not just be that of vector)?

I'm all for improving the interface but the goal of vector-bytestring
is that it can be used as a drop-in replacement for bytestring without
changing to much code.

Regards,

Bas