Changes

Page history
Edit InfixTypeConstructors authored by Simon Peyton Jones's avatar Simon Peyton Jones
Show whitespace changes
Inline Side-by-side
infix-type-constructors.md
View page @ a9d0bea7
......@@ -43,40 +43,21 @@ And `type` gets an extra production:
(modulo [FixityResolution](fixity-resolution)). 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 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.
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 down-sides, 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/type-extensions.html#infix-tycons) 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 type-family 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 type-synonym families, they really are *functions* as much as any value-level 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 back-quotes 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 back-quotes 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))
......@@ -101,3 +82,28 @@ We'd have to use a type variable in back-quotes instead.
data a `Foo` b = a `FOO` a `Bar` b
data a `Bar` b = a `BAR` b
```
## References
- [ Infix type constructors, classes, and type variables](http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#infix-tycons) 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 back-quotes instead.