[Haskell-cafe] The difficulty of designing a sequence class

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Mon Jul 31 11:53:47 EDT 2006

On Mon, 2006-07-31 at 16:27 +0100, Brian Hulley wrote:

> None of the above type classes would be compatible with Data.ByteString! 
> (You mentioned this issue before wrt Data.Edison.Seq but it just clicked 
> with me now for the above refactoring.) For compatibility, the element type 
> would need to appear also thus:
>    class Foldable f_a a | f_a -> a where
>         fold :: (a -> b -> b) -> b -> f_a -> b
>    class Reduce f_a a | f_a -> a where
>         reduceR :: (a -> b -> b) -> (f_a -> b -> b)
>         reduceL :: (b -> a -> b) -> (b -> f_a -> b)
>    instance Reduce [a] a where
>         reduceR  f  l  x = foldr f  x  l
>         -- etc
> Thus Data.ByteString, as well as being extremely useful to store strings 
> (!), is a central lynchpin in the entire re-factoring question since it's an 
> example of a  non-polymorphic collection type (or a collection with 
> restricted polymorphism), and supporting it would require a redesign of 
> existing ideas in this direction eg 
> http://cvs.haskell.org/Hugs/pages/libraries/base/Data-Foldable.html is no 
> use either.

Indeed. There seem to be several new classes appearing in GHC 6.6 which
we will not be able to make ByteString an instance of for just these

If these are seeking to eventually replace the prelude versions of map,
fold etc then it would be nice if they were general enough to cover
specialised containers like ByteStrings, unboxed arrays or bitmaps of

You'll note that the array type classes solve this, as you suggest, by
adding the element type as a parameter to the class. This allows for
instances that are polymorphic in the element, like Array and instances
which only support specific element types like UArray.


More information about the Haskell-Cafe mailing list