On 17 October 2011 13:12, Christian Maeder <christian.mae...@dfki.de> wrote: > Am 17.10.2011 12:14, schrieb Bas van Dijk: >> >> On 17 October 2011 10:18, Christian Maeder<christian.mae...@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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
