After reading your email i went to the discussion of IArray on the haskell doc page (http://www.haskell.org/ghc/docs/latest/set/sec-iarray.html) and am somewhat disturbed by it. There is the introduction of the following class:
class HasBounds a where bounds :: Ix ix => a ix e -> (ix,ix)
which is then used in:
class HasBounds a => IArray a e where array :: Ix ix => (ix,ix) -> [(ix,e)] -> a ix e (!) :: ... (//) :: ...
It was factored this way because for certain array types we define a separate IArray instance for each element type (ie. for the unboxed UArray types), where for these types the definition of 'bounds' doesn't depend on the element type so it would be wasteful to include it in the IArray class.
class Ix ix => HasBounds a ix | a -> ix where bounds :: a -> (ix,ix)
Surely you mean class Ix ix => HasBounds a ix | a -> ix where bounds :: a e -> (ix,ix) ^^ don't forget the 'e'!
that way, we would efine things like:
instance Ix ix => HasBounds (Array.Array ix) ix where ... instance Ix ix => HasBounds (UArray ix) ix where ...
Yes, this looks reasonable. Then of course Ix becomes a superclass of HasBounds and hence also of IArray, which will change quite a few types. I do remember trying various renderings of these two classes before I settled on these though: in particular I think making Ix a superclass caused problems (but I can't remember what exactly). Perhaps you could try it and let me know? Cheers, Simon