+++ /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