| 16 | == Design choices == |

| 17 | |

| 18 | Should kind inference be done before, or after expanding type synonyms? That is, should a type synonym have a fixed kind or not? |

| 19 | |

| 20 | Currently GHC does kind inference before expanding type synonyms, and gives each type synonym a fixed kind. The following program is rejected: |

| 21 | |

| 22 | {{{ |

| 23 | type T f a = f a |

| 24 | |

| 25 | x :: T (T (,) Int) Float |

| 26 | x = (1,2.0) |

| 27 | }}} |

| 28 | gives |

| 29 | {{{ |

| 30 | syn.hs:5:10: |

| 31 | `(,)' is not applied to enough type arguments |

| 32 | Expected kind `* -> *', but `(,)' has kind `* -> * -> *' |

| 33 | In the type `T (,) Int' |

| 34 | In the type `T (T (,) Int) Float' |

| 35 | In the type signature for `x': |

| 36 | x :: T (T (,) Int) Float |

| 37 | }}} |

| 38 | |

| 39 | In favour of GHC's approach is that type errors are more likely to be given in terms of types that the programmer actually wrote. However, this does reject more programs, and perhaps it would be simpler to treat type synonyms uniformly as macros, without kinds? |

| 40 | |