chak 2005/05/09 21:11:27 PDT
Modified files: (Branch: ghc-assoc-branch)
ghc/compiler/deSugar DsMeta.hs
ghc/compiler/hsSyn Convert.lhs HsDecls.lhs
ghc/compiler/main HscStats.lhs
ghc/compiler/parser Parser.y.pp ParserCore.y RdrHsSyn.lhs
ghc/compiler/rename RnBinds.lhs RnNames.lhs RnSource.lhs
ghc/compiler/typecheck TcInstDcls.lhs TcRnMonad.lhs
TcTyClsDecls.lhs
Log:
Associated Data Types
---------------------
This is the initial commit towards implementing associated data types (ie,
data and newtype declarations in type classes). The language extension
and implementation follows the specification in the corresponding POPL'05
paper. However, there are some refinements; the currently implemented ones
are listed below.
This commit covers:
* HsSyn and parser extension to allow data and newtype declarations in class
and instance declarations.
* Renamer processes associated data/newtype declarations and propagates
associated declarations from instance to the toplevel (in particular, the
data constructors get into the GlobalRdrEnv).
* Kind checking is performed on associated data type declarations (ie, they
are traversed in the kind checking knot of TcTyClsDecls).
-=-
Refinement of the specification in the POPL'05 paper:
* Kind signatures can only occur on the type variables that are in excess of
the class parameters in an associated type declaration (in a type class
declaration). Rationale: The binding position for the class parameters is
the class head. That's where the signatures should be.
* Associated data type definitions (in instances) can have kind signatures at
type variables introduced in the head. These signatures must be compatible
with the kinds inferred for the declaration of the associated data type. In
particular, if an AT definition has a variable-only parameter with a kind
signature, this signature must match the corresponding signature at the AT
declaration or the class declaration (if it is a class parameter). If there
is no signature, and hence, the variable's kind was inferred as being *, the
only signature allowed at the definition is *. Rationale: We need to allow
extra kind signatures, as type indexes may introduce new variables, which we
cannot annotate in any other way. Moreover, to keep the story simple, we
allow signatures at all variables and simply require that they are
compatible with the kinds inferred for declarations. NB: The definition is
such that there is never a need to propagate kind information from an AT
definition to the corresponding AT declaration or class declaration.
* The declaration of an associated data type in a class can have a deriving
clause. The meaning is that all instances of that type inherit all these
derivings (or do we merely want to force them to state - at least - these
derivings). Rationale: If I want equality on an associated type, I need to
guarantee that all its variants come with an equality.
Revision Changes Path
1.72.4.1 +1 -1 fptools/ghc/compiler/deSugar/DsMeta.hs
1.63.4.1 +11 -3 fptools/ghc/compiler/hsSyn/Convert.lhs
1.110.4.1 +42 -17 fptools/ghc/compiler/hsSyn/HsDecls.lhs
1.14.10.1 +1 -1 fptools/ghc/compiler/main/HscStats.lhs
1.30.2.1 +59 -18 fptools/ghc/compiler/parser/Parser.y.pp
1.22.2.1 +2 -2 fptools/ghc/compiler/parser/ParserCore.y
1.86.4.1 +117 -35 fptools/ghc/compiler/parser/RdrHsSyn.lhs
1.96.4.1 +1 -0 fptools/ghc/compiler/rename/RnBinds.lhs
1.196.2.1 +18 -2 fptools/ghc/compiler/rename/RnNames.lhs
1.174.2.1 +157 -20 fptools/ghc/compiler/rename/RnSource.lhs
1.176.2.1 +2 -1 fptools/ghc/compiler/typecheck/TcInstDcls.lhs
1.53.2.1 +6 -1 fptools/ghc/compiler/typecheck/TcRnMonad.lhs
1.126.2.1 +18 -3 fptools/ghc/compiler/typecheck/TcTyClsDecls.lhs
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
