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