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

[Duncan Coutts]

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
reasons.

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
pixels.

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.

Duncan