H98: Ix class

[Simon Peyton-Jones]

Folks, (esp Matt, Jan-Willem)

Back from ICFP, I have resumed my increasingly small circles around the
Revised Haskell 98 Report.

In an earlier message (which I enclose for your convenience) I proposed
to:
	a) Remove Ord from Ix's superclasses
	b) Add rangeSize to Ix's methods (with a suitable default
method)

As we implemented these changes we discovered that change (a) actually
breaks existing programs.  Of course it does: now you have to add Ord to
the signature of any function that compares indices.  This really does
happen (for example, it happens even in the code for the Array library
in the Report).

I should have realised this before, but=20
=09
		I therefore withdraw proposal (a).

It now looks like a perhaps-desirable, but definitely un-forced change,
and that goes beyond my remit.

However (b) doesn't break anything, I think, so I propose to let it
stand.
(The two are independent I think.)

Does anyone want to argue that having Ord as a superclass of Ix is So
Bad
that it Absolutely Must Be Removed?

Simon

-----Original Message-----
From: Simon Peyton-Jones=20
Sent: 17 May 2001 17:52
To: Matt Harden; Haskell list
Subject: RE: Ix class


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]
| 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
| 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
| 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
| 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
| 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
| 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
| 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

_______________________________________________
Haskell mailing list
Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell