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