| 22 | |

| 23 | Secondly, I propose to allow varsyms to be used as type ''constructors''. For example, currently "+" is a varsym, so at the type level it'd behave like a type ''variable'' |

| 24 | {{{ |

| 25 | data T (+) = MkT (Int + Int) |

| 26 | }}} |

| 27 | It's not impossible that this might be useful, although the binding site looks clumsy. But it misses a much more useful opportunity. What we ''want'' is to say |

| 28 | {{{ |

| 29 | data a + b = Left a | Right b |

| 30 | }}} |

| 31 | That is, we want to define the type ''constructor'' `(+)`. Currently we have to use the clumsy `:+` notation: |

| 32 | {{{ |

| 33 | data a :+ b = Left a | Right b |

| 34 | }}} |

| 35 | Yuk. '''So I propose that varsyms can be used as type constructors, and not as type variables.''' |

| 36 | |

| 37 | You may say that is inconsistent, because at the value level you have to start data constructors with a ":". But the type level is already funny. The whole type-family idea (beginning with type synonyms) defines things that begin with a capital letter, but which (unlike data constructors) are not head normal forms. By the time we have full type-synonym families, they really are *functions* as much as any value-level function is. |

| 38 | |

| 39 | Some people use Haskell as a laboratory in which to write their cunning type ideas. In mathematics, operators are invariably top-level type constructors (think of the type a+b). Mirroring this in Haskell would make the transcription more elegantly direct. |

| 40 | |

| 41 | I can't think of any down-sides, except the slight loss of consistency ("the hobgoblin of tiny minds"). |

| 42 | |