# IArray

**Simon Marlow
**
simonmar@microsoft.com

*Mon, 25 Feb 2002 12:10:54 -0000*

>* After reading your email i went to the discussion of IArray=20
*>* on the haskell
*>* doc page=20
*>* (http://www.haskell.org/ghc/docs/latest/set/sec-iarray.html) and
*>* am somewhat disturbed by it. There is the introduction of=20
*>* the following
*>* class:
*>*=20
*>* > class HasBounds a where
*>* > bounds :: Ix ix =3D> a ix e -> (ix,ix)
*>*=20
*>* which is then used in:
*>*=20
*>* > class HasBounds a =3D> IArray a e where
*>* > array :: Ix ix =3D> (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 =3D> HasBounds a ix | a -> ix where
*>* > bounds :: a -> (ix,ix)
*
Surely you mean=20
class Ix ix =3D> HasBounds a ix | a -> ix where
bounds :: a e -> (ix,ix)
^^
don't forget the 'e'!
>* that way, we would efine things like:
*>*=20
*>* > instance Ix ix =3D> HasBounds (Array.Array ix) ix where ...
*>* > instance Ix ix =3D> 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