... | ... | @@ -3,23 +3,21 @@ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**Ticket:** [\#25](https://gitlab.haskell.org//haskell/prime/issues/25)
|
|
|
|
|
|
|
|
|
|
|
|
## Brief Explanation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The proposal is to allow empty `data` declarations, i.e. data types without any
|
|
|
constructors. Syntactically, it is basically just a matter of making the
|
|
|
"`=` *constrs*" part optional in the context free syntax. Semantically,
|
|
|
the result is a type (once the type constructor has been fully applied)
|
|
|
whose only element is bottom. Examples (assuming
|
|
|
[Infix Type Constructors](infix-type-constructors) is adopted):
|
|
|
|
|
|
|
|
|
|
|
|
```wiki
|
... | ... | @@ -33,10 +31,9 @@ data (a :**: b) c |
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
[Kind inference](kind-inference) will of course be carried out for types constructors
|
|
|
introduced by empty declarations just as for any other type constructors according to
|
|
|
whatever rules are adopted. Unless there are further constraints the kinds of the
|
|
|
whatever rules are adopted. Unless there are further constraints, the kinds of the
|
|
|
constructors above would be
|
|
|
|
|
|
|
... | ... | @@ -48,7 +45,6 @@ T :: * -> * |
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
If [kind annotations](kind-annotations) are adopted, they should obviously also apply
|
|
|
to empty declarations. They would possibly be a little more important for empty declarations,
|
|
|
though, as empty declarations lack(!) any data constructors to suggest the intended kind of
|
... | ... | @@ -58,10 +54,14 @@ non-empty types, especially if one of the more refined versions of [kind inferen |
|
|
is adopted. [Polymorphic kinds](kind-inference) would make this point moot, though, as kind
|
|
|
annotations then never would be needed, unless it is decided that kind annotations still would
|
|
|
be good documentation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that contexts of course also would be allowed, but, as there are no data constructors, their
|
|
|
only impact would be on the inferred kind.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The only real issue is whether or not to allow the optional `deriving` clause after an empty declaration,
|
|
|
and, if not, on what stage to rule them out. Clearly, as there are no data constructors over which to
|
|
|
define functions, derived instances would (for consistency) have to be everywhere undefined. GHC seems
|
... | ... | @@ -69,7 +69,6 @@ to syntactically allow a `deriving` clause after an empty data declaration, but |
|
|
contextual error since no interesting instances can be defined. Presumably the reasoning was that this
|
|
|
gives a more regular syntax and better error messages than ruling out deriving for empty declarations
|
|
|
syntactically. But the point is that there is a choice.
|
|
|
|
|
|
|
|
|
|
|
|
## References
|
... | ... | @@ -88,19 +87,11 @@ syntactically. But the point is that there is a choice. |
|
|
<td>Add infix type constructors</td></tr></table>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Pros
|
|
|
|
|
|
|
|
|
- A simple and natural generalisation of data declarations, seemingly without any hidden complications.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Cons
|
|
|
|
|
|
|