[Haskell-cafe] Are associated types synonyms like type classes?

[Bulat Ziganshin]

Hello Brian,

Saturday, September 2, 2006, 10:19:17 PM, you wrote:

> What is the practical difference between class A and class B? With
> class A we can define instances so that f is overloaded (Int ->
> Bool), (String -> Bool), (Bool -> Bool) by defining instances of A
> for Int, String, and Bool, but we cannot overload it more (Int ->
> String), (Int -> Int) because we can only have on "instance A Int".
> The converse is true for class B. Is that the only difference? 

> If so, then why do we have "associated types" instance of "associated classes" like this?:
>  
>     class A a where
>        class B b where
>            f :: a -> b

>     instance A Int where 
>         instance B Bool where
>             f = (==0)

class defines a set of types, type defines just one type. So, defining
class inside class or using your hand-made syntax we will got just the
same thing as MPTC:

> The made-up syntax I presented in my previous message was just a
> different way of writing the above (which is also made-up syntax):

>     class A a, B b where f :: a -> b
>     instance A Int, B Bool where f = (==0)

using associated type inside class is a way to define many-to-one
relationship, i.e. it's the same as MPTC+FD

>     class Elem elem, Collect collect where
>         empty :: collect
>         insert :: elem -> collect -> collect
>         toList :: collect -> [elem]

your syntax differs from MPTC only in that we have two class names -
Elem and Collect, but that is not that we need - we need type
restrictions that joins collection with its element types:

insertMany :: (Collection c e) => [e] -> c -> c

if we will try to use different class names here, the requirement to
insert into collection elements it can hold, will not be expressed:

insertMany :: (Elem e, Collect c) => [e] -> c -> c



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com