[Haskell-cafe] Arguments against an hypothetical Data.ByteString.Generic?

[Yves Parès]

Oh, okay ^^ sorry, my bad. I should have compiled with -Wall.

So I started a repo at https://github.com/YwenP/bytestring-generic


Le 27 mars 2012 22:01, Bas van Dijk <v.dijk.bas at gmail.com> a écrit :

> On 27 March 2012 21:46, Yves Parès <yves.pares at gmail.com> wrote:
> > Yes, thank you to remind me of that, I remember now having seen the
> project.
> > Strict ByteStrings being an alias to Vector Word8 is a good idea (are
> > bytestrings are already implemented exactly like
> > Data.Vector.Storable.Vector). But in that case we could use the API of
> > vector for bytestrings (the bytestring API would be provided only for
> > backwards compatibility, right?).
>
> Yes, I hope that one day the bytestring package and the ByteString
> type will be deprecated in favor of vector and
> Data.Vector.Storable.Vector Word8 respectively. vector-bytestring is
> indeed intended as a package which should make the transition easier.
>
> > Does vector-bytestring plans to be the new implementation for
> bytestrings in
> > the end or is it a side-package?
>
> I hope that once we get on par with bytestring's performance we can
> replace it (we're almost there!, Yell if you want to see some
> benchmark results).
>
> >> In an ideal world we would have a Lazy type family which for each type
> >> of vector would return its lazy version
> >
> > What about a type like:
> >
> > data Vector v a = Empty | Chuck {-# UNPACK #-} !(v a) (Vector v a)
> > ??
>
> If you build with -Wall you'll see the following unfortunate warning:
>
> Warning: Ignoring unusable UNPACK pragma on the
>             first argument of `Chunk'
>
> Johan Tibell recently discussed some of his ideas on how to solve this:
>
>
> http://www.haskell.org/pipermail/glasgow-haskell-users/2012-March/022079.html
>
> But for now we need to make a specialized type for every different
> vector type and use an associated type family to abstract over these
> different types.
>
> Regards,
>
> Bas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120327/da8333dd/attachment.htm>