IArray

[Simon Marlow]

> 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