[project @ 2004-11-10 03:20:31 by wolfgang]

[ghc-hetmet.git] / ghc / docs / comm / the-beast / vars.html

diff --git a/ghc/docs/comm/the-beast/vars.html b/ghc/docs/comm/the-beast/vars.html
index 55d11ee..9bbd310 100644 (file)
--- a/ghc/docs/comm/the-beast/vars.html
+++ b/ghc/docs/comm/the-beast/vars.html
@@ -26,10 +26,12 @@ represents variables, both term variables and type variables:
 </pre>
 <ul>
 <li> The <code>varName</code> field contains the identity of the variable:
-its unique number, and its print-name.  The unique number is cached in the
-<code>realUnique</code> field, just to make comparison of <code>Var</code>s a little faster.
+its unique number, and its print-name.  See "<a href="names.html">The truth about names</a>".
 
-<p><li> The <code>Type</code> field gives the type of a term variable, or the kind of a
+<p><li> The <code>realUnique</code> field caches the unique number in the
+<code>varName</code> field, just to make comparison of <code>Var</code>s a little faster.
+
+<p><li> The <code>varType</code> field gives the type of a term variable, or the kind of a
 type variable.  (Types and kinds are both represented by a <code>Type</code>.)
 
 <p><li> The <code>varDetails</code> field distinguishes term variables from type variables,
@@ -57,6 +59,7 @@ We define a couple of type synonyms:
 just to help us document the occasions when we are expecting only term variables,
 or only type variables.
 
+
 <h2> The <code>VarDetails</code> field </h2>
 
 The <code>VarDetails</code> field tells what kind of variable this is:
@@ -70,19 +73,28 @@ data VarDetails
 
   | TyVar
   | MutTyVar (IORef (Maybe Type))      -- Used during unification;
-            Bool                       -- True <=> this is a type signature variable, which
-                                       --          should not be unified with a non-tyvar type
+            TyVarDetails
 </pre>
 
+<a name="TyVar">
 <h2>Type variables (<code>TyVar</code>)</h2>
-
-The <code>TyVar</code> case is self-explanatory.  The
-<code>MutTyVar</code> case is used only during type checking.  Then a
-tupe variable can be unified, using an imperative update, with a type,
-and that is what the <code>IORef</code> is for.  The <code>Bool</code>
-field records whether the type variable arose from a type signature,
-in which case it should not be unified with a type (only with another
-type variable).
+</a>
+<p>
+The <code>TyVar</code> case is self-explanatory.  The <code>MutTyVar</code>
+case is used only during type checking.  Then a type variable can be unified,
+using an imperative update, with a type, and that is what the
+<code>IORef</code> is for.  The <code>TcType.TyVarDetails</code> field records
+the sort of type variable we are dealing with.  It is defined as
+<pre>
+data TyVarDetails = SigTv | ClsTv | InstTv | VanillaTv
+</pre>
+<code>SigTv</code> marks type variables that were introduced when
+instantiating a type signature prior to matching it against the inferred type
+of a definition.  The variants <code>ClsTv</code> and <code>InstTv</code> mark
+scoped type variables introduced by class and instance heads, respectively.
+These first three sorts of type variables are skolem variables (tested by the
+predicate <code>isSkolemTyVar</code>); i.e., they must <em>not</em> be
+instantiated. All other type variables are marked as <code>VanillaTv</code>.
 <p>
 For a long time I tried to keep mutable Vars statically type-distinct
 from immutable Vars, but I've finally given up.   It's just too painful.
@@ -204,28 +216,20 @@ to find calls to overloaded functions, <em>and then discards the <code>SpecPragm
 So <code>SpecPragma</code> behaves a like <code>Exported</code>, at least until the specialiser.
 
 
-<h3>Global and Local <code>Name</code>s</h3>
+<h3> ExternalNames and InternalNames </h3>
 
 Notice that whether an Id is a <code>LocalId</code> or <code>GlobalId</code> is 
-not the same as whether the Id has a <code>Local</code> or <code>Global</code> <code>Name</code>:
+not the same as whether the Id has an <code>ExternaName</code> or an <code>InternalName</code>
+(see "<a href="names.html#sort">The truth about Names</a>"):
 <ul>
-<li> Every <code>GlobalId</code> has a <code>Global</code> <code>Name</code>.
+<li> Every <code>GlobalId</code> has an <code>ExternalName</code>.
 <li> A <code>LocalId</code> might have either kind of <code>Name</code>.
 </ul>
-The significance of Global vs Local names is this:
-<ul>
-<li> A <code>Global</code> Name has a module and occurrence name; a <code>Local</code> 
-has only an occurrence name.
-<p> <li> A <code>Global</code> Name has a unique that never changes.  It is never
-cloned.  This is important, because the simplifier invents new names pretty freely,
-but we don't want to lose the connnection with the type environment (constructed earlier).
-A <code>Local</code> name can be cloned freely.
-</ul>
-
 
 <!-- hhmts start -->
-Last modified: Wed Aug  8 19:23:01 EST 2001
+Last modified: Fri Sep 12 15:17:18 BST 2003
 <!-- hhmts end -->
     </small>
   </body>
 </html>
+