[Haskell-cafe] Help with Type Class

[Alson Kemp]

Bulat,

BZ>AK>   class CollectionClass c e where
BZ>this works with -fglasgow-exts :
Yup.  Figured that out shortly after I e-mailed... 
Thank you for providing the extra detail, though. 
-fglasgow-exts fixed the problem, but I didn't have a
good idea why the problem went away.


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.
 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
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?  

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

Thanks for the help.

- Alson