Changes between Version 3 and Version 4 of EmptyDataDecls

Oct 23, 2006 7:08:28 PM (9 years ago)



  • EmptyDataDecls

    v3 v4  
    11= Empty data declarations = 
    44'''Ticket:''' #25 
    66== Brief Explanation == 
     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): 
     16data S 
     18data T a 
     20data a :*: b 
     22data (a :**: b) c 
     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 
     30S :: * 
     31T :: * -> * 
     32(:*:) :: * -> * -> * 
     33(:**:) :: * -> * -> * -> * 
     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. 
     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. 
     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. 
    857== References == 
    958 * [] GHC documentation. 
     59 * [[TicketQuery(description~=KindInference)]] 
     60 * [[TicketQuery(description~=KindAnnotations)]] 
     61 * [[TicketQuery(description~=InfixTypeConstructors)]] 
    1163== Pros == 
     64 * A simple and natural generalisation of data declarations, seemingly without any hidden complications. 
    1466== Cons ==