[project @ 2005-05-12 12:55:32 by chak]
[ghc-hetmet.git] / ghc / docs / comm / the-beast / types.html
1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
2 <html>
3   <head>
4     <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
5     <title>The GHC Commentary - Hybrid Types</title>
6   </head>
7
8   <body BGCOLOR="FFFFFF">
9     <h1>The GHC Commentary - Hybrid Types</h1>
10     <p>
11       GHC essentially supports two type systems: (1) the <em>source type
12         system</em> (which is a heavily extended version of the type system of
13       Haskell 98) and the <em>Core type system,</em> which is the type system
14       used by the by far most important intermediate language (see also <a
15       href="desugar.html">Sugar Free: From Haskell To Core</a>).
16     </p>
17     <p>
18       During parsing and renaming, type information is represented in a form
19       that is very close to Haskell's concrete syntax; it is defined by
20       <code>HsTypes.HsType</code>.  In addition, type, class, and instance
21       declarations are maintained in their source form as defined in the
22       module <code>HsDecl</code>.  The situation changes during type checking,
23       where types are translated into a second representation, which is
24       defined in the module <code>types/TypeRep.lhs</code>, as type
25       <code>Type</code>.  This second representation is peculiar in that it is
26       a hybrid between the source representation of types and the Core
27       representation of types.  Using functions, such as
28       <code>Type.coreView</code> and <code>Type.deepCoreView</code>, a value
29       of type <code>Type</code> exhibits its Core representation.  On the
30       other hand, pretty printing a <code>Type</code> with
31       <code>TypeRep.pprType</code> yields the type's source representation.
32     </p>
33     <p>
34       In fact, the <a href="typecheck.html">type checker</a> maintains type
35       environments based on <code>Type</code>, but needs to perform type
36       checking on source-level types.  As a result, we have functions
37       <code>Type.tcEqType</code> and <code>Type.tcCmpType</code>, which
38       compare types based on their source representation, as well as the
39       function <code>coreEqType</code>, which compares them based on their
40       core representation.  The latter is needed during type checking of Core
41       (as performed by the functions in the module
42       <code>coreSyn/CoreLint.lhs</code>). 
43     </p>
44
45     <h2>Type Synonyms</h2>
46     <p>
47       Type synonyms in Haskell are essentially a form of macro definitions on
48       the type level.  For example, when the type checker compares two type
49       terms, synonyms are always compared in their expanded form.  However, to
50       produce good error messages, we like to avoid expanding type synonyms
51       during pretty printing.  Hence, <code>Type</code> has a variant
52       <code>NoteTy TyNote Type</code>, where
53     </p>
54     <blockquote>
55       <pre>
56 data TyNote
57   = FTVNote TyVarSet    -- The free type variables of the noted expression
58
59   | SynNote Type        -- Used for type synonyms
60                         -- The Type is always a TyConApp, and is the un-expanded form.
61                         -- The type to which the note is attached is the expanded form.</pre>
62     </blockquote>
63     <p>
64       In other words, a <code>NoteTy</code> represents the expanded form of a
65       type synonym together with a note stating its source form.
66     </p>
67
68     <h2>Newtypes</h2>
69     <p>
70       Slightly more involved are data types declared via a
71       <code>newtype</code> declaration.  These newtypes constitute new type
72       constructors---i.e., they are not just type macros, but introduce new
73       type names.  However, provide that a newtype is not recursive, we still
74       want to implement it by its representation type.  In other words,
75       <code>tcEqType</code> cannot see through a newtype, but
76       <code>coreEqType</code> can.
77     </p>
78
79     <h2>Predicates</h2>
80     <p>
81       The dictionary translation of type classes, translates each predicate in
82       a type context of a type signature into an additional argument, which
83       carries a dictionary with the functions overloaded by the corresponding
84       class.  The <code>Type</code> data type has a special variant
85       <code>PredTy PredType</code> for predicates, where
86     </p>
87     <blockquote>
88       <pre>
89 data PredType 
90   = ClassP Class [Type]         -- Class predicate
91   | IParam (IPName Name) Type   -- Implicit parameter</pre>
92     </blockquote>
93     <p>
94       These types need to be handled as source type during type checking, but
95       turn into their representations when inspected through
96       <code>coreView</code>.  The representation is determined by
97       <code>Type.predTypeRep</code>.
98     </p>
99
100     <h2>Classes and Instances</h2>
101     <p>
102       Class declarations turn into values of type <code>Class.Class</code>.
103       They represent methods as the <code>Id</code>s of the dictionary
104       selector functions.  Similar selector functions are available for
105       superclass dictionaries.
106     </p>
107     <p>
108       Instance declarations turn into values of type
109       <code>InstEnv.Instance</code>, which in interface files are represented
110       as <code>IfaceSyn.IfaceInst</code>.  Moreover, the type
111       <code>InstEnv.InstEnv</code>, which is a synonym for <code>UniqFM
112       ClsInstEnv</code>, provides a mapping of classes to their instances -
113       <code>ClsInstEnv</code> is essentially a list of instance declarations.
114     </p>
115
116     <p><small>
117 <!-- hhmts start -->
118 Last modified: Thu May 12 22:47:50 EST 2005
119 <!-- hhmts end -->
120     </small></p>
121   </body>
122 </html>