[Haskell-cafe] The Proliferation of List-Like Types

[Roman Leshchinskiy]

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