Changes between Version 2 and Version 3 of Design/TypeNaming


Ignore:
Timestamp:
Sep 23, 2008 10:50:47 PM (6 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Design/TypeNaming

    v2 v3  
    106106=== Proposal 1: disambiguation in export lists and fixity declarations === 
    107107 
    108  * Extend export lists and fixity declarations to permit the disambiguating specifier `data`, `type`, and `class`. 
    109  * The specifier is always permitted, but only required if the situation would otherwise be ambiguous. 
    110  * The specifier must match the corresponding declaration, except that the specifier `data` matches a `newtype` declaration too. 
     108 * Extend export lists and fixity declarations to permit the 
     109   disambiguating specifier `data`, `type`, and `class`. 
     110 * The specifier is always permitted, but only required if the 
     111   situation would otherwise be ambiguous. 
     112 * The specifier must match the corresponding declaration, except that 
     113   the specifier `data` matches a `newtype` declaration too.  (This 
     114   "except" is arguable. The idea is that someone looking at the 
     115   export list doesn't need to know whether the type is declared with 
     116   `data` or `newtype`, whereas for `type` synonyms they do need to 
     117   know.) 
    111118 
    112119Thus you can say 
     
    175182notation must be reasonably quiet. 
    176183 
     184 
    177185=== Alternatives to proposal 2 === 
    178186 
     
    187195   (Obvious question: the overlap with the module qualifiers.) 
    188196 
    189 Neither of these alternatives seem compatible with lists and  
     197 * Not every data type type can be lifted to the kind level; for 
     198   example, existentials and GADTS!  It seems messy to have this done 
     199   or not done silently; perhaps there should be some indication in 
     200   the data type declaration to say "make this available as a kind 
     201   too".  Or perhaps the whole idea of automatic lifting isn't worth 
     202   the candle, and we should should provide explicit `datakind`. 
     203 
     204None of these alternatives seem compatible with lists and  
    190205tuples at the type level. Maybe they can still use the "`%`" notation?