[Haskell-cafe] Help with Type Class

Daniel Fischer daniel.is.fischer at web.de
Thu Mar 2 09:46:58 EST 2006


Am Mittwoch, 1. März 2006 20:20 schrieben Sie:
> Daniel,
>
> > >   data Array i e = Array i i
> >
> > shouldn't the element type appear here?
>
> Typo: data Array i e = Array i i [e] --mockup with
> list
>
> > Well, the parameter c of CollectionClass has kind (*
> > -> *), Array has kind
> > (* -> * -> *), so it must be
> > instance CollectionClass (Array i) e where ...
>
> ... which (I think) was breaking until -fglasgow-exts.

Well, Haskell98 doesn't allow multiparameter type classes, so extensions are 
required.

>  Once that was fixed, this seems to be the preferred
> way to implement this function.
>
> > But the element type doesn't really belong in the
> > class, wouldn't class Collection c where
> >     toList :: c e -> [e]
>
> Hmmm...  For example, implementing Array and UArray as
> subclasses of Collection:
>   class Collection c where
>     toList :: c e -> [e]
>   instance Collection (Array i) where
>     toList a = ...
>   instance Collection (UArray i) where
>     toList a = ...
>
> If Collection is not parameterized on "e", then there
> is no way to make sure that the "e" in Collection
> (UArray i):toList is actually "unboxable".  As with

Ah, I see. I didn't think of that.

> the current IArray implementation, the following works
> and isn't particularly limiting in flexibility:
>   class Collection c e where
>     toList :: c e -> [e]
>   instance Collection (Array i) e where
>     toList a = ...
>   instance Collection (UArray i) Int where --note the
> Int
>     toList a = ...
>
> I understand trying to make Collection as general as
> possible by removing "e", but it look as if doing so
> makes useful subclasses difficult to implement?

Making Collection a single parameter class doesn't increase generality, I 
believe, but I thought that creating a collection was a property of the type 
constructor c alone, so the element type didn't really belong to the class. 
However, the UArray example gives a good reason to include it.
>
> > -- or perhaps, better
> > class Collection c => ArrayLike c i | c -> i where
> >     look :: Monad m => i -> c e -> m e
> > be preferable?
>
> ermm...  Need to read up on Functional Dependencies...
>  brb...

Thus we can declare
instance ArrayLike [] Int where
    look 0 (x:_) = return x
...
>
> Thanks for the help.
>
> - Alson

Cheers,
Daniel

-- 

"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
	-- Blair P. Houghton



More information about the Haskell-Cafe mailing list