[Haskell-cafe] The Proliferation of List-Like Types
rl at cse.unsw.edu.au
Wed Feb 20 21:42:56 EST 2008
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,
> 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
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
> 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.
More information about the Haskell-Cafe