| | 24 | At the moment, when you define a type family without `-XPolyKinds` like this: |
| | 25 | {{{ |
| | 26 | type family F a |
| | 27 | }}} |
| | 28 | it gets kind `* -> *`. There are no constraints on the kind of `a`, so we |
| | 29 | default it to `*`. We also default the return kind of `F` to `*`. |
| | 30 | The same happens for data families, and also for plain datatypes with phantom |
| | 31 | types. |
| | 32 | |
| | 33 | When you turn `-XPolyKinds` on, however, we currently give `F` the kind |
| | 34 | `forall (k :: BOX). k -> *`. This is unsatisfactory for two reasons: |
| | 35 | |
| | 36 | 1. The behaviour of kind generalisation changes when we turn `-XPolyKinds` on, |
| | 37 | even though it doesn't really have to. We could still default to `*` unless |
| | 38 | you give a kind signature. So if you want `F` to be kind polymorphic, you |
| | 39 | should write `type family F (a :: k)`. This, of course, requires supporting |
| | 40 | [GhcKinds#Explicitkindvariables explicit kind variables]. |
| | 41 | |
| | 42 | 2. Unlike the parameters, however, the return kind of `F` is defaulted to `*`. |
| | 43 | This seems rather arbitrary. We should either generalise both arguments and |
| | 44 | return kind, or default both. In case we choose to default, the more |
| | 45 | general kind can be obtained by giving a signature: |
| | 46 | {{{ |
| | 47 | type family F (a :: k1) :: k2 |
| | 48 | }}} |
| | 49 | |
| | 50 | '''Future work:''' do more consistent kind defaulting. |
| | 51 | |
| | 52 | |
