[Haskell-cafe] Equality constraints in type families

Manuel M T Chakravarty chak at cse.unsw.edu.au
Tue Mar 25 21:33:26 EDT 2008


Claus Reinke wrote,
> given that type families are never meant to be partially applied,  
> perhaps a different notation, avoiding confusion
> with type constructor applications in favour of something
> resembling products, could make that clearer?
>
> something simple, like braces to group families and indices:
>
>   type family {F a} :: * -> *
>   {F x} y ~ {F u} v <=> {F x} ~ {F u} && y ~ v
>
> would avoid confusion about which parameters need
> to be present (no partial application possible) and are
> subject to family instance rules, and which parameters are subject  
> to the decomposition rule.


and David Menendez wrote,
> erhaps type families could use a different kind constructor to
> distinguish type indexes from type parameters.
>
> Currently, Haskell kinds are generated by this grammar:
>
>   kind ::= "*" | kind "->" kind
>
> We create a new production for "family kinds",
>
>   fkind ::= kind | kind "-|>" fkind
>
> Now, we can easily distinguish F and G,
>
>   F :: * -|> * -> *
>   G :: * -|> * -|> *
>
> The grammar allows higher-kinded indexes, like (* -> *) -|> *, but
> requires all indexes to precede the regular parameters. (That is, you
> can't abstract over a family.)

Yes, this is something that we thought about, too.  In the System FC  
paper, we subscript all type families with their arity to achieve a  
weak form of this; ie, we'd write

   F_1 Int Bool

to make clear that (F_1 Int) is a non-decomposable family application,  
where the outermost application in ((F_1 Int) Bool) is decomposable.

The extra syntax has its advantages (more local information) and  
disadvantages (more clutter).  We weren't convinced that we need the  
extra syntax, so left it out for the moment. However, this is  
something that can always be changed if experience shows that programs  
are easier to understand with extra syntax.  It doesn't affect the  
type theory and is really a pure language design question.  I'd be  
glad to hear some more opinions about this matter.

Manuel



More information about the Haskell-Cafe mailing list