Changes between Version 2 and Version 3 of KindAnnotations
- Timestamp:
- 02/02/06 03:56:24 (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
KindAnnotations
v2 v3 1 1 = Kind Annotations = 2 2 3 Ghc permits type expressions (or is it only type variables?) to be annotated with a kind signature. See [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#sec-kinding this section] of the ghc user guide. 3 == Brief explanation == 4 4 5 In Haskell 98, each type constructor and variable has a kind. 6 Though the Report uses a notation for kinds, they do not appear in Haskell source. 7 8 GHC permits types and new type constructors and variables to be annotated with a kind signature, e.g. 5 9 {{{ 6 10 type T (f :: * -> *) = f Int 7 11 }}} 8 12 13 == References == 14 * [http://www.haskell.org/onlinereport/decls.html#sect4.1.1 Kinds] in the Haskell 98 report 15 * [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#sec-kinding Explicitly-kinded quantification] in the GHC User's Guide 16 17 == Tickets == 18 [[TicketQuery(description~=KindAnnotations)]] 19 9 20 == Pros == 10 * Without the ability to write a kind signature, there are cases where one must introduce dummy data constructors purely for their effect in forcing a higher-kindedness on a type variable. 21 * Allows more machine-checked documentation. 22 * Haskell 98 defaults kinds to `*`, which is a nuisance if you want a higher kind. 23 Kind annotations remove the need for awkward workarounds like dummy data constructors. 24 See KindInference for alternative solutions to this problem. 11 25 12 26 == Cons == … … 15 29 == Proposal == 16 30 17 To adopt explicit kind annotations as part of the language, more or less exactly as ghc permits. 18 Ticket: #84 31 To adopt explicit kind annotations as part of the language, more or less exactly as GHC permits.
