Cale Gibbard wrote:
<snip>
Thanks for the illustration - I see another advantage with type classes is
that you only need to write the type signature once (in the class
declaration) instead of before each instance binding.
Secondly, if the functions are really different, and you never plan to
use them polymorphically, why the heck would you want to call them the
same thing? That's just confusing to anyone that has to read the code
later.
For example, Data.Map declares:
insert :: Ord k => k -> a -> Map k a -> Map k a
whereas Data.Set declares:
insert :: Ord a => a -> Set a -> Set a
This is an example where type classes can't be applied even though the
functions in a sense do the same thing. My system would solve this problem,
by allowing the programmer to type d = insert a b c and have the type
inference algorithm work out that Data.Map.insert was meant, as long as c or
d has been typed as Map p q.
But perhaps there is a way to get the signature for Data.Map.insert into the
same form as that of Data.Set.insert?
Regards, Brian.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
