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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe