
On 17 October 2011 18:28, Christian Maeder
Am 17.10.2011 17:26, schrieb Bas van Dijk:
On 17 October 2011 13:12, Christian Maeder
wrote: 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).
Yes, but Data.Vector.Storable can be simple imported and used in addition.
I consider that an advantage.
I suppose, the (derived) Data instances (from vector and the original bytestrings) break the abstraction. (So you must hope nobody is relying on this instance.)
Good point! I will mention that in the documentation of vector-bytestring. Also code using the ByteString constructor PS has to be changed because I obviously can't provide an equivalent. However the documentation of Data.ByteString.Internal (which exports PS) warns "normal" users not to use that module: "A module containing semi-public 'ByteString' internals. This exposes the 'ByteString' representation and low level construction functions. As such all the functions in this module are unsafe. The API is also not stable. Where possible application should instead use the functions from the normal public interface modules, such as "Data.ByteString.Unsafe". Packages that extend the ByteString system at a low level will need to use this module." So I expect not many packages are using the PS constructor directly which means the pain of switching to vectors will be minimal.
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.
Changing back to another drop-in replacement for bytestring will be difficult if functions from Data.Vector.Storable have been used.
True, so lets try to make this the final replacement ;-) Regards, Bas