Changes between Version 14 and Version 15 of TypeFunctions


Ignore:
Timestamp:
Jul 31, 2006 6:59:04 PM (9 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TypeFunctions

    v14 v15  
    3535Type function (kind) signatures are represented by the new declaration form `TyFunction` (of `HsDecls.TyClDecl`).  Syntactically, we recognise kind signatures by either not having an RHS at all (in which the result kind implicitly is *) or having a result kind separated from the head by {{{::}}}.  We require that every type equation has a kind signature in scope.  However, the degenerate case of a type equation where all type arguments are variables is valid without a kind signature (in fact, it may not have any) and coincides with the type synonyms of vanilla Haskell.
    3636
    37 === Type declarations in classes and indexed types ===
     37=== Representation of indexed types ===
    3838
    39 Adding types declarations to classes is fairly straight forward. The {{{ClassDecl}}} variant of {{{TyClDecl}}} gets a new field {{{tcdATs}}}, which contains a list of type declarations - currently, the parser will only allow data type declarations. Similarly, {{{InstDecl}}} gets a fourth argument, which is a list of type declarations.
     39==== Type function signatures ====
     40
     41`HsDecls.TyClDecl` has a new variant `HsFunction` to represent signatures of type functions.  These consist of the name, type parameters, an iso flag, and optionally an explicit result kind.  The type parameters can have kind signatures as usual.
     42
     43==== Type function equations and definitions of associated data types ====
    4044
    4145More tricky is the addition of type indexes (i.e., non-type variable arguments) to data type declarations. The grammar is already very general and allows arbitrary arguments, but the parser uses {{{RdHsSyn.checkTyClHdr}}} to construct the AST and that function ensures that only type variables are supplied. The new story is that {{{checkTyClHdr}}} can operate in two different modes: (1) checking mode and (2) extraction mode. Checking mode corresponds to the original behaviour. In extraction mode, all free type variables of the arguments will be collected, but we don't enforce that the arguments are themselves merely type variables. When processing class headers (and for the moment also type synonyms), we use {{{checkTyClHdr}}} in checking mode as before. However, when processing a data type (or newtype) declaration, we use extraction mode and keep both the list of type variables (as {{{tcdTyVars}}}) and the original arguments (as {{{tcdTyPats}}}) in the representation of data type declarations (i.e., in the variant {{{TyData}}} of {{{TyClDecl}}}). The check enforcing that all arguments to top-level data type declarations and the non-class parameter arguments of associated data types are variables is delayed until the renamer (as we need context information). In the renamer, we check that non-variable type parameters can only occur in the first few arguments of ATs and we remove these parameters by floating the associated data type declarations to the top-level.
    4246
    4347In the parser, we put the original type terms specified as parameters in the field {{{tcdTyPats}}}. For top-level declarations, after checking that the parameters are all plain type variables (possibly with a kind signature), we reset {{{tcdTyPats}}} to {{{Nothing}}} (this already happens during AST construction). {{{DataDecls}}} created during parsing Core are already born with {{{tcdTyPats}}} being Nothing. (Although, the latter may change.)
     48
     49=== Representation of associated types ===
     50
     51Adding types declarations to classes is fairly straight forward. The {{{ClassDecl}}} variant of {{{TyClDecl}}} gets a new field {{{tcdATs}}}, which contains a list of type declarations - currently, the parser will only allow data type declarations. Similarly, {{{InstDecl}}} gets a fourth argument, which is a list of type declarations.
    4452
    4553=== Phasing ===