|
|
|
# Liberal Type Synonyms
|
|
|
|
|
|
|
|
## Brief Explanation
|
|
|
|
|
|
|
|
|
|
|
|
See the [ GHC Documentation](http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#type-synonyms) on this extension.
|
|
|
|
|
|
|
|
|
|
|
|
The basic idea is that type validity checking is done *after expanding type synonyms*.
|
|
|
|
This means, for example, that type synonyms can be written unsaturated, as long as the result of expanding synonyms leaves everything saturated. This is sometimes quite useful.
|
|
|
|
|
|
|
|
|
|
|
|
There are also interactions with [RankNTypes](rank-n-types) - a type synonym may expand to a quantified type.
|
|
|
|
|
|
|
|
## Proposal
|
|
|
|
|
|
|
|
## Brief Explanation
|
|
|
|
|
|
|
|
Adopt GHC's approach to type synonym expansion. Specifically, these conditions are checked only *after* expansion:
|
|
|
|
|
|
|
|
- No partial applications of type synonyms
|
|
|
|
- No 'forall' types as an argument to a type constructor
|
|
|
|
- An instance head is of form `C (T ...)`, where `T` is a *data* type.
|
|
|
|
|
|
|
|
|
|
|
|
However these conditions may be broken *before* expansion of type synonyms.
|
|
|
|
See the [ GHC Documentation](http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#type-synonyms) on this extension.
|
|
|
|
|
|
|
|
## Kind checking
|
|
|
|
|
|
|
|
|
|
|
|
Should kind checking be done before, or after expanding type synonyms? That is, should a type synonym have a fixed kind or not?
|
|
|
|
The basic idea is that type validity checking is done *after expanding type synonyms*. This means that type synonyms can be written unsaturated, as long as the result of expanding synonyms leaves everything saturated. This is sometimes quite useful.
|
|
|
|
|
|
|
|
|
|
|
|
Currently GHC does kind inference before expanding type synonyms, and gives each type synonym a fixed kind. The following program is rejected:
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
type T f a = f a
|
|
|
|
There are also interactions with [RankNTypes](rank-n-types) - a type synonym may expand to a quantified type.
|
|
|
|
|
|
|
|
x :: T (T (,) Int) Float
|
|
|
|
x = (1,2.0)
|
|
|
|
```
|
|
|
|
|
|
|
|
## Proposal
|
|
|
|
|
|
|
|
gives
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
syn.hs:5:10:
|
|
|
|
`(,)' is not applied to enough type arguments
|
|
|
|
Expected kind `* -> *', but `(,)' has kind `* -> * -> *'
|
|
|
|
In the type `T (,) Int'
|
|
|
|
In the type `T (T (,) Int) Float'
|
|
|
|
In the type signature for `x':
|
|
|
|
x :: T (T (,) Int) Float
|
|
|
|
```
|
|
|
|
|
|
|
|
Adopt GHC's approach to type synonym expansion.
|
|
|
|
|
|
|
|
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?
|
|
|
|
|
|
|
|
## References
|
|
|
|
|
|
|
|
|
|
|
|
- [ GHC Documentation](http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#type-synonyms)
|
|
|
|
|
|
|
|
## Tickets
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<table><tr><th>[\#102](https://gitlab.haskell.org//haskell/prime/issues/102)</th>
|
|
|
|
<td>add Liberal Type Synonyms</td></tr></table>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Pros
|
|
|
|
|
|
|
|
|
|
|
|
- Small generalisation
|
|
|
|
- Easily specified
|
|
|
|
- Quite handy
|
|
|
|
|
|
|
|
## Cons
|
|
|
|
|
|
|
|
- It's so … syntactic.
|
|
|
|
- There are the usual worries about deferred checking leading to less
|
|
|
|
informative diagnostics. |
|
|
|
|
|
|
|
- any? |