Changes between Version 2 and Version 3 of Design/TypeNaming


Ignore:
Timestamp:
Sep 23, 2008 10:50:47 PM (7 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?