From: chak Date: Tue, 13 Nov 2001 03:28:03 +0000 (+0000) Subject: [project @ 2001-11-13 03:28:03 by chak] X-Git-Tag: Approximately_9120_patches~577 X-Git-Url: http://git.megacz.com/?p=ghc-hetmet.git;a=commitdiff_plain;h=6c2b22efbcc3f213b24b53b832ba9901ea5954bd [project @ 2001-11-13 03:28:03 by chak] A little more info about type checking --- diff --git a/ghc/docs/comm/the-beast/typecheck.html b/ghc/docs/comm/the-beast/typecheck.html index 0cbd5bf..6f3c07c 100644 --- a/ghc/docs/comm/the-beast/typecheck.html +++ b/ghc/docs/comm/the-beast/typecheck.html @@ -11,6 +11,47 @@ Probably the most important phase in the frontend is the type checker, which is located at fptools/ghc/compiler/typecheck/. + GHC type checks programs in their original Haskell form before the + desugarer converts them into Core code. This complicates the type + checker as it has to handle the much more verbose Haskell AST, but it + improves error messages, as the those message are based on the same + structure that the user sees. +

+ GHC defines the abstract syntax of Haskell programs in HsSyn + using a structure that abstracts over the concrete representation of + bound occurences of identifiers and patterns. The module TcHsSyn + instantiates this structure for the type checker using TcEnv.TcId + to represent identifiers - in fact, a TcId is currently + nothing but just a synonym for a plain + Id. + +

Types Variables and Zonking

+

+ During type checking type variables are represented by mutable variables + - cf. the variable story. Consequently, + unification can instantiate type variables by updating those mutable + variables. This process of instantiation is (for reasons that elude + me) called zonking + in GHC's sources. The zonking routines for the various forms of Haskell + constructs are responsible for most of the code in the module TcHsSyn, + whereas the routines that actually operate on mutable types are defined + in TcMTypes; + this includes routines to create mutable structures and update them as + well as routines that check constraints, such as that type variables in + function signatures have not been instantiated during type checking. + The actual type unification routine is uTys in the same + module. +

+ All type variables that may be instantiated (those in signatures + may not), but haven't been instantiated during type checking, are zonked + to (), so that after type checking all mutable variables + have been eliminated.

Type Checking Environment

@@ -89,7 +130,7 @@

-Last modified: Wed Aug 8 19:24:09 EST 2001 +Last modified: Tue Nov 13 14:28:44 EST 2001 diff --git a/ghc/docs/comm/the-beast/vars.html b/ghc/docs/comm/the-beast/vars.html index a3060bf..455cc31 100644 --- a/ghc/docs/comm/the-beast/vars.html +++ b/ghc/docs/comm/the-beast/vars.html @@ -74,8 +74,10 @@ data VarDetails -- should not be unified with a non-tyvar type +

Type variables (TyVar)

- + +

The TyVar case is self-explanatory. The MutTyVar case is used only during type checking. Then a type variable can be unified, using an imperative update, with a type, @@ -224,7 +226,7 @@ A Local name can be cloned freely. -Last modified: Wed Aug 8 19:23:01 EST 2001 +Last modified: Tue Nov 13 14:11:35 EST 2001