On Wed, Feb 20, 2008 at 08:39:13AM -0600, John Goerzen wrote:
I am concerned that the same thing is happening in Haskell. We now have three common list-like types: the regular list, strict ByteString, and lazy ByteString.
This has created some annoying situations. For instance, a ByteString is great for reading data fast, but Parsec doesn't work on ByteStrings. I am glad that someone wrote a Parsec equivalent that does[1], which answers a real need. But this means that all the combinators in the hsemail library that implement standard RFC conventions won't be usable in my ByteString code, for instance. [...] http://software.complete.org/listlike/static/doc/ListLike/Data-ListLike.html
As Henning pointed out, multiple parameter type classes are problematic for core libraries at present. An alternative might be explicit dictionaries. For example, a partial solution would be to provide coinductive views, i.e. for all these types to provide functions of a type like full -> Maybe (item, full) (Data.Map, Data.Set and Data.Sequence would each have two such functions), and to have a library of generalized functions taking such functions as parameters, like splitAt :: (full -> Maybe (item, full)) -> Int -> full -> ([item], full) Parsing libraries could include a similar parameter within their monad. That only covers the elimination side, of course.