John Goerzen wrote:
I am concerned that the same thing is happening in Haskell. We know have three common list-like types: the regular list, strict ByteString, and lazy ByteString.
Why do you consider ByteString to be list-like but not arrays?
1) Does everyone agree with me that we have a problem here?
Yes, definitely. Haskell simply lacks a standard container library.
2) Would it make sense to make ListLike, or something like it, part of the Haskell core?
I don't think ListLike is the right approach. It's basically a fairly arbitrary collection of functions. It would be preferable, IMO, to identify a small set of combinators which would allow most list/sequence functions to be implemented generically and efficiently. Personally, I'd go with something like streams (the stream fusion ones) but I'm biased, of course.
3) Would it make sense to base as much code as possible in the Haskell core areound ListLike definitions? Here I think of functions such as lines and words, which make sense both on [Char] as well as ByteStrings.
Yes, as long as there are only very few core combinators. The more methods your ListLike class has, the harder it is to justify why a new function should be implemented in terms of those and not included in the class.
4) We are missing one final useful type: a Word32-based ByteString. When working in the Unicode character set, a 32-bit character can indeed be useful, and I could see situations in which the performance benefit of a ByteString-like implementation could be useful combared to [Char].
I have to disagree somewhat. What we are missing is a nice, efficient array library. There is nothing magical about ByteStrings, they are just unboxed arrays. In fact, there is no good reason for ByteString to be a separate type at all.
Roman _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
