1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
4 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
5 <title>The GHC Commentary - Hybrid Types</title>
8 <body BGCOLOR="FFFFFF">
9 <h1>The GHC Commentary - Hybrid Types</h1>
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>).
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.
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>).
45 <h2>Type Synonyms</h2>
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
57 = FTVNote TyVarSet -- The free type variables of the noted expression
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>
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.
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.
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
90 = ClassP Class [Type] -- Class predicate
91 | IParam (IPName Name) Type -- Implicit parameter</pre>
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>.
100 <h2>Classes and Instances</h2>
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.
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.
118 Last modified: Thu May 12 22:47:50 EST 2005