Ix class

[Simon Peyton-Jones]

I rather agree with Matt's message below.
I'm desperately trying NOT to change the H98 libraries, but this
is a very non-disruptive change, as he points out,
and it does lift two apparently-unnecessary restrictions.

a) Remove Ord from Ix's superclasses
b) Add rangeSize to Ix's methods

Does anyone have any thoughts about this.
(We made a similar change to Random, adding=20
a method.)

Simon

| -----Original Message-----
| From: Matt Harden [mailto:matth@mindspring.com]=20
| Sent: 16 May 2001 00:43
| To: Haskell list
| Subject: Ix class
|=20
|=20
| Hello,
|=20
| I am working on an Ix instance for one of my types and=20
| finding it rather restrictive.  For me it would be useful to=20
| have rangeSize be defined in the Ix class (with a default=20
| definition of course), so that it can be overridden.
|=20
| Also, does anybody know why Ix derives from Ord?  It seems to=20
| me this is an unnecessary limitation on the types that can be=20
| instances of Ix.  I cannot think of a reason why the=20
| implementation of anything in the Ix or Array modules would=20
| require that every Ix be an Ord (with a minor exception --=20
| see below).  If an implementation is using a comparison on an=20
| Ix type, chances are it should be using inRange or comparing=20
| (index bnds x) with (index bnds y) instead.
|=20
| One change would have to be made in the Array module if Ord=20
| is removed from Ix:
| 	instance  (Ix a, Eq b)  =3D> Eq (Array a b)  where
| 	    a =3D=3D a'             =3D  assocs a =3D=3D assocs a'
| 	instance  (Ix a, Ord b) =3D> Ord (Array a b)  where
| 	    a <=3D  a'            =3D  assocs a <=3D  assocs a'
|=20
| would become:
| 	instance  (Ix a, Eq a, Eq b)   =3D> Eq (Array a b)  where
| 	    a =3D=3D a'             =3D  assocs a =3D=3D assocs a'
| 	instance  (Ix a, Ord a, Ord b) =3D> Ord (Array a b)  where
| 	    a <=3D  a'            =3D  assocs a <=3D  assocs a'
|=20
| As I said, I think this is a very minor issue.
|=20
| I believe that making these changes in the standard would not=20
| impact existing programs in any way.  Could these changes be=20
| considered as a possible "typo" to be fixed in the Library Report?
|=20
|=20
| P.S. In case anybody's interested, here's why I want to override
| rangeSize:
|=20
| > newtype Honeycomb =3D Hx (Int,Int) deriving (Eq,Show,Ord)
| >=20
| > indexError =3D error "Index out of range"
| >=20
| > instance Ix Honeycomb where
| >    range   (Hx b1, Hx b2) =3D
| >       [Hx x | x <- range (b1,b2), isHexIx x]
| >    inRange (Hx b1, Hx b2) (Hx x) =3D
| >       inRange (b1,b2) x && isHexIx x
| >    index   (Hx b1, Hx b2) (Hx x) =3D
| >       let i =3D index (b1,b2) x in
| >          if isHexIx x then i `div` 2 else indexError
| >=20
| > isHexIx :: (Int,Int) -> Bool
| > isHexIx (x,y) =3D x `mod` 2 =3D=3D y `mod` 2
|=20
| This implements a honeycomb or hexagonal tiling for a maze=20
| generating program.  The honeycomb is superimposed on a grid=20
| such that only every other square is "active", corresponding=20
| to a particular hexagon in the honeycomb.  It's similar to a=20
| checkers game, where only the dark squares are used.
|=20
| I would like _any_ pair of Ints to be an acceptable boundary=20
| for the honeycomb, not just the ones that represent valid=20
| indexes.  For example, (Hx (0,0), Hx (15,12)) should be a=20
| valid set of bounds.  The current definition of rangeSize=20
| makes this impossible, which is why I would like to override=20
| it.  By the way, the Library Report does not explicitly say=20
| that the bounds have to both be valid indexes, though it does=20
| imply this with the sample definition of rangeSize.
|=20
| Thanks,
| Matt Harden
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20