Changes between Version 3 and Version 4 of EmptyDataDecls


Ignore:
Timestamp:
Oct 23, 2006 7:08:28 PM (9 years ago)
Author:
nhn@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • EmptyDataDecls

    v3 v4  
    11= Empty data declarations =
    22[[PageOutline]]
    3 
     3 
    44'''Ticket:''' #25
    5 
     5 
    66== Brief Explanation ==
    7 
     7 
     8The proposal is to allow empty `data` declarations, i.e. data types without any
     9constructors. Syntactically, it is basically just a matter of making the
     10"`=` ''constrs''" part optional in the context free syntax. Semantically,
     11the result is a type (once the type constructor has been fully applied)
     12whose only element is bottom. Examples (assuming
     13[wiki:InfixTypeConstructors Infix Type Constructors] is adopted):
     14 
     15{{{
     16data S
     17 
     18data T a
     19 
     20data a :*: b
     21 
     22data (a :**: b) c
     23}}}
     24 
     25[wiki:KindInference Kind inference] will of course be carried out for types constructors
     26introduced by empty declarations just as for any  other type constructors according to
     27whatever rules are adopted. Unless there are further constraints the kinds of the
     28constructors above would be
     29{{{
     30S :: *
     31T :: * -> *
     32(:*:) :: * -> * -> *
     33(:**:) :: * -> * -> * -> *
     34}}}
     35 
     36If [wiki:KindAnnotations kind annotations] are adopted, they should obviously also apply
     37to empty declarations. They would possibly be a little more important for empty declarations,
     38though, as empty declarations lack(!) any data constructors to suggest the intended kind of
     39the type arguments. Thus, for a human reader, working out from the program text what the
     40inferred kind of a type constructor for an empty type is would seem a tad harder than for
     41non-empty types, especially if one of the more refined versions of [wiki:KindInference kind inference]
     42is adopted. [wiki:KindInference Polymorphic kinds] would make this point moot, though, as kind
     43annotations then never would be needed, unless it is decided that kind annotations still would
     44be good documentation.
     45                                                                               
     46Note that contexts of course also would be allowed, but, as there are no data constructors, their
     47only impact would be on the inferred kind.
     48                                                                               
     49The only real issue is whether or not to allow the optional `deriving` clause after an empty declaration,
     50and, if not, on what stage to rule them out. Clearly, as there are no data constructors over which to
     51define functions, derived instances would (for consistency) have to be everywhere undefined. GHC seems
     52to syntactically allow a `deriving` clause after an empty data declaration, but the treats it as a
     53contextual error since no interesting instances can be defined. Presumably the reasoning was that this
     54gives a more regular syntax and better error messages than ruling out deriving for empty declarations
     55syntactically. But the point is that there is a choice.
     56                                                                               
    857== References ==
    958 * [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#nullary-types] GHC documentation.
    10 
     59 * [[TicketQuery(description~=KindInference)]]
     60 * [[TicketQuery(description~=KindAnnotations)]]
     61 * [[TicketQuery(description~=InfixTypeConstructors)]]
     62                                                                               
    1163== Pros ==
    12 
    13 
     64 * A simple and natural generalisation of data declarations, seemingly without any hidden complications.
     65                                                                               
    1466== Cons ==