--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+ <head>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
+ <title>The GHC Commentary - Hybrid Types</title>
+ </head>
+
+ <body BGCOLOR="FFFFFF">
+ <h1>The GHC Commentary - Hybrid Types</h1>
+ <p>
+ GHC essentially supports two type systems: (1) the <em>source type
+ system</em> (which is a heavily extended version of the type system of
+ Haskell 98) and (2) the <em>Core type system,</em> which is the type system
+ used by the intermediate language (see also <a
+ href="desugar.html">Sugar Free: From Haskell To Core</a>).
+ </p>
+ <p>
+ During parsing and renaming, type information is represented in a form
+ that is very close to Haskell's concrete syntax; it is defined by
+ <code>HsTypes.HsType</code>. In addition, type, class, and instance
+ declarations are maintained in their source form as defined in the
+ module <code>HsDecl</code>. The situation changes during type checking,
+ where types are translated into a second representation, which is
+ defined in the module <code>types/TypeRep.lhs</code>, as type
+ <code>Type</code>. This second representation is peculiar in that it is
+ a hybrid between the source representation of types and the Core
+ representation of types. Using functions, such as
+ <code>Type.coreView</code> and <code>Type.deepCoreView</code>, a value
+ of type <code>Type</code> exhibits its Core representation. On the
+ other hand, pretty printing a <code>Type</code> with
+ <code>TypeRep.pprType</code> yields the type's source representation.
+ </p>
+ <p>
+ In fact, the <a href="typecheck.html">type checker</a> maintains type
+ environments based on <code>Type</code>, but needs to perform type
+ checking on source-level types. As a result, we have functions
+ <code>Type.tcEqType</code> and <code>Type.tcCmpType</code>, which
+ compare types based on their source representation, as well as the
+ function <code>coreEqType</code>, which compares them based on their
+ core representation. The latter is needed during type checking of Core
+ (as performed by the functions in the module
+ <code>coreSyn/CoreLint.lhs</code>).
+ </p>
+
+ <h2>Type Synonyms</h2>
+ <p>
+ Type synonyms in Haskell are essentially a form of macro definitions on
+ the type level. For example, when the type checker compares two type
+ terms, synonyms are always compared in their expanded form. However, to
+ produce good error messages, we like to avoid expanding type synonyms
+ during pretty printing. Hence, <code>Type</code> has a variant
+ <code>NoteTy TyNote Type</code>, where
+ </p>
+ <blockquote>
+ <pre>
+data TyNote
+ = FTVNote TyVarSet -- The free type variables of the noted expression
+
+ | SynNote Type -- Used for type synonyms
+ -- The Type is always a TyConApp, and is the un-expanded form.
+ -- The type to which the note is attached is the expanded form.</pre>
+ </blockquote>
+ <p>
+ In other words, a <code>NoteTy</code> represents the expanded form of a
+ 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>
+ Data types declared by a <code>newtype</code> declarations 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>
+ <p>
+ The dictionary translation of type classes, translates each predicate in
+ a type context of a type signature into an additional argument, which
+ carries a dictionary with the functions overloaded by the corresponding
+ class. The <code>Type</code> data type has a special variant
+ <code>PredTy PredType</code> for predicates, where
+ </p>
+ <blockquote>
+ <pre>
+data PredType
+ = ClassP Class [Type] -- Class predicate
+ | IParam (IPName Name) Type -- Implicit parameter</pre>
+ </blockquote>
+ <p>
+ These types need to be handled as source type during type checking, but
+ turn into their representations when inspected through
+ <code>coreView</code>. The representation is determined by
+ <code>Type.predTypeRep</code>.
+ </p>
+
+ <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 available
+ 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 two both include their original right hand side;
+ in addition, the third variant also caches 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
+ selector functions. Similar selector functions are available for
+ superclass dictionaries.
+ </p>
+ <p>
+ Instance declarations turn into values of type
+ <code>InstEnv.Instance</code>, which in interface files are represented
+ as <code>IfaceSyn.IfaceInst</code>. Moreover, the type
+ <code>InstEnv.InstEnv</code>, which is a synonym for <code>UniqFM
+ ClsInstEnv</code>, provides a mapping of classes to their
+ instances---<code>ClsInstEnv</code> is essentially a list of instance
+ declarations.
+ </p>
+
+ <p><small>
+<!-- hhmts start -->
+Last modified: Sun Jun 19 13:07:22 EST 2005
+<!-- hhmts end -->
+ </small></p>
+ </body>
+</html>
projects / ghc-hetmet.git / blobdiff