From 848100338eec665215f44dbde9687ae69dd34d2a Mon Sep 17 00:00:00 2001
From: chak <unknown>
Date: Tue, 24 May 2005 04:45:15 +0000
Subject: [PATCH] [project @ 2005-05-24 04:45:15 by chak] More details about
 the representation of types after type checking.

---
 ghc/docs/comm/the-beast/types.html |   73 +++++++++++++++++++++++++++++++-----
 1 file changed, 64 insertions(+), 9 deletions(-)

diff --git a/ghc/docs/comm/the-beast/types.html b/ghc/docs/comm/the-beast/types.html
index 359cbf5..762a4c4 100644
--- a/ghc/docs/comm/the-beast/types.html
+++ b/ghc/docs/comm/the-beast/types.html
@@ -65,15 +65,44 @@ data TyNote
       type synonym together with a note stating its source form.
     </p>
 
+    <h3>Creating Representation Types of Synonyms</h3>
+    <p>
+      During translation from <code>HsType</code> to <code>Type</code> the
+      function <code>Type.mkSynTy</code> is used to construct representations
+      of applications of type synonyms.  It creates a <code>NoteTy</code> node
+      if the synonym is applied to a sufficient number of arguments;
+      otherwise, it builds a simple <code>TyConApp</code> and leaves it to
+      <code>TcMType.checkValidType</code> to pick up invalid unsaturated
+      synonym applications.  While creating a <code>NoteTy</code>,
+      <code>mkSynTy</code> also expands the synonym by substituting the type
+      arguments for the parameters of the synonym definition, using
+      <code>Type.substTyWith</code>.
+    </p>
+    <p>
+      The function <code>mkSynTy</code> is used indirectly via
+      <code>mkGenTyConApp</code>, <code>mkAppTy</code>, and
+      <code>mkAppTy</code>, which construct type representations involving
+      type applications.  The function <code>mkSynTy</code> is also used
+      directly during type checking interface files; this is for tedious
+      reasons to do with forall hoisting - see the comment at
+      <code>TcIface.mkIfTcApp</code>. 
+    </p>
+
     <h2>Newtypes</h2>
     <p>
-      Slightly more involved are data types declared via a
-      <code>newtype</code> declaration.  These newtypes constitute new type
-      constructors---i.e., they are not just type macros, but introduce new
-      type names.  However, provide that a newtype is not recursive, we still
-      want to implement it by its representation type.  In other words,
-      <code>tcEqType</code> cannot see through a newtype, but
-      <code>coreEqType</code> can.
+      Data types declared by a <code>newtype</code> declarationx constitute new
+      type constructors---i.e., they are not just type macros, but introduce
+      new type names.  However, provided that a newtype is not recursive, we
+      still want to implement it by its representation type.  GHC realises this
+      by providing two flavours of type equality: (1) <code>tcEqType</code> is
+      source-level type equality, which compares newtypes and
+      <code>PredType</code>s by name, and (2) <code>coreEqType</code> compares
+      them structurally (by using <code>deepCoreView</code> to expand the
+      representation before comparing).  The function
+      <code>deepCoreView</code> (via <code>coreView</code>) invokes
+      <code>expandNewTcApp</code> for every type constructor application
+      (<code>TyConApp</code>) to determine whether we are looking at a newtype
+      application that needs to be expanded to its representation type.
     </p>
 
     <h2>Predicates</h2>
@@ -97,7 +126,33 @@ data PredType
       <code>Type.predTypeRep</code>.
     </p>
 
-    <h2>Classes and Instances</h2>
+    <h2>Representation of Type Constructors</h2>
+    <p>
+      Type constructor applications are represented in <code>Type</code> by
+      the variant <code>TyConApp :: TyCon -> [Type] -> Type</code>.  The first
+      argument to <code>TyConApp</code>, namely <code>TyCon.TyCon</code>,
+      distinguishes between function type constructors (variant
+      <code>FunTyCon</code>) and algebraic type constructors (variant
+      <code>AlgTyCon</code>), which arise from data and newtype declarations.
+      The variant <code>AlgTyCon</code> contains all the information contained
+      from the data/newtype declaration as well as derived information, such
+      as the <code>Unique</code> and argument variance information.  This
+      includes a field <code>algTcRhs :: AlgTyConRhs</code>, where
+      <code>AlgTyConRhs</code> distinguishes three kinds of algebraic data
+      type declarations: (1) declarations that have been exported abstractly,
+      (2) <code>data</code> declarations, and (3) <code>newtype</code>
+      declarations.  The last of these both include their original right hand
+      side as well as the "ultimate" representation type, which is the right
+      hand side after expanding all type synonyms and non-recursive newtypes.
+    </p>
+    <p>
+      Both data and newtype declarations refer to their data constructors
+      represented as <code>DataCon.DataCon</code>, which include all details
+      of their signature (as derived from the original declaration) as well
+      information for code generation, such as their tag value.
+    </p>
+
+    <h2>Representation of Classes and Instances</h2>
     <p>
       Class declarations turn into values of type <code>Class.Class</code>.
       They represent methods as the <code>Id</code>s of the dictionary
@@ -115,7 +170,7 @@ data PredType
 
     <p><small>
 <!-- hhmts start -->
-Last modified: Thu May 12 22:47:50 EST 2005
+Last modified: Tue May 24 14:44:18 EST 2005
 <!-- hhmts end -->
     </small></p>
   </body>
-- 
1.7.10.4