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