...  ...  @@ 43,40 +43,21 @@ And `type` gets an extra production: 


(modulo [FixityResolution](fixityresolution)). Also, there are obvious changes to the grammar for `type`, `data`, and `newtype` declarations.









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 typefamily 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 typesynonym families, they really are \*functions\* as much as any valuelevel function is.









Some people use constructors (think of the type a+b). Mirroring this in Haskell would make the transcription more elegantly direct.









I can't think of any downsides, except the slight loss of consistency ("the hobgoblin of tiny minds").






## References






 [ Infix type constructors, classes, and type variables](http://www.haskell.org/ghc/docs/latest/html/users_guide/typeextensions.html#infixtycons) in the GHC User's Guide.






## Tickets






<table><tr><th>[\#78](https://gitlab.haskell.org//haskell/prime/issues/78)</th>



<td>Add infix type constructors</td></tr></table>






## Pros






 This is a straightforward generalisation, doesn't break any existing code, and improves the consistency of the syntax.






## Cons



## Observations






 If operators are type constructors, they can't also be type variables. I know one place where people use a type variable that is an operator. Something like this.



 You may say that it's inconsistent for `(+)` to range over type constructors, because at the value level you have to start data constructors with a ":". But the type level is already funny. The whole typefamily idea (including H98 type synonyms) defines things that begin with a capital letter, but which (unlike data constructors) are not head normal forms. Looking further ahead, by the time we have full typesynonym families, they really are *functions* as much as any valuelevel function is. For example it would be silly to insist on a leading colon here:






```wiki



data T (~>) = MkT (Int ~> Int)



type family (+) :: * > * > *



type instance Zero + n2 = n2



type instance (Succ n1) + n2 = Succ (n1 + n2)



```









We'd have to use a type variable in backquotes instead.






## Observations






 Note that classes can be infix too; this is useful.






 If you say `module M( (+) ) where ...` are you exporting the type constructor `(+)` or the value `(+)`? Ditto import lists. Possibilities:

...  ...  @@ 90,7 +71,7 @@ We'd have to use a type variable in backquotes instead. 


 Need to allow infix notation in contexts






```wiki



f :: (a :>: b) => bla blah



f :: (a >> b) => bla blah



```



 Watch out for code like this ([ http://hackage.haskell.org/trac/ghc/ticket/1727](http://hackage.haskell.org/trac/ghc/ticket/1727))




...  ...  @@ 100,4 +81,29 @@ We'd have to use a type variable in backquotes instead. 





data a `Foo` b = a `FOO` a `Bar` b



data a `Bar` b = a `BAR` b



``` 


\ No newline at end of file 


```






## References






 [ Infix type constructors, classes, and type variables](http://www.haskell.org/ghc/docs/latest/html/users_guide/typeextensions.html#infixtycons) in the GHC User's Guide.






## Tickets






<table><tr><th>[\#78](https://gitlab.haskell.org//haskell/prime/issues/78)</th>



<td>Add infix type constructors</td></tr></table>






## Pros






 This is a straightforward generalisation, and doesn't break any existing code (except code that uses GHC extensions to have a type variable that is an operator).



 It's very useful to write type expressions like `(a + b)`.






## Cons






 If operators are type constructors, they can't also be type variables. I know one place where people use a type variable that is an operator. Something like this.






```wiki



data T (~>) = MkT (Int ~> Int)



```









We'd have to use a type variable in backquotes instead. 