+ +This chapter was thoroughly changed Feb 2003. + +
+ data T a = MkT !(a,a) !(T a) | Nil + + f x = case x of + MkT p q -> MkT p (q+1) + Nil -> Nil ++The user's source program mentions only the constructors MkT +and Nil. However, these constructors actually do something +in addition to building a data value. For a start, MkT evaluates +its arguments. Secondly, with the flag -funbox-strict-fields GHC +will flatten (or unbox) the strict fields. So we may imagine that there's the +source constructor MkT and the representation constructor +MkT, and things start to get pretty confusing. +
+GHC now generates three unique Names for each data constructor: +
+ ---- OccName ------ + String Name space Used for + --------------------------------------------------------------------------- + The "source data con" MkT DataName The DataCon itself + The "worker data con" MkT VarName Its worker Id + aka "representation data con" + The "wrapper data con" $WMkT VarName Its wrapper Id (optional) ++Recall that each occurrence name (OccName) is a pair of a string and a +name space (see The truth about names), and +two OccNames are considered the same only if both components match. +That is what distinguishes the name of the name of the DataCon from +the name of its worker Id. To keep things unambiguous, in what +follows we'll write "MkT{d}" for the source data con, and "MkT{v}" for +the worker Id. (Indeed, when you dump stuff with "-ddumpXXX", if you +also add "-dppr-debug" you'll get stuff like "Foo {- d rMv -}". The +"d" part is the name space; the "rMv" is the unique key.) +
+Each of these three names gets a distinct unique key in GHC's name cache. + +
+ data T a = MkT !(a,a) !Int | Nil + + f x = case x of + Nil -> Nil + MkT p q -> MkT p (q+1) ++When the parser reads it in, it decides which name space each lexeme comes +from, thus: +
+ data T a = MkT{d} !(a,a) !Int | Nil{d}
+
+ f x = case x of
+ Nil{d} -> Nil{d}
+ MkT{d} p q -> MkT{d} p (q+1)
+
+Notice that in the Haskell source all data contructors are named via the "source data con" MkT{d},
+whether in pattern matching or in expressions.
++In the translated source produced by the type checker (-ddump-tc), the program looks like this: +
+ f x = case x of
+ Nil{d} -> Nil{v}
+ MkT{d} p q -> $WMkT p (q+1)
+
+
+Notice that the type checker replaces the occurrence of MkT by the wrapper, but
+the occurrence of Nil by the worker. Reason: Nil doesn't have a wrapper because there is
+nothing to do in the wrapper (this is the vastly common case).
++Though they are not printed out by "-ddump-tc", behind the scenes, there are +also the following: the data type declaration and the wrapper function for MkT. +
+ data T a = MkT{d} a a Int# | Nil{d}
+
+ $WMkT :: (a,a) -> T a -> T a
+ $WMkT p t = case p of
+ (a,b) -> seq t (MkT{v} a b t)
+
+Here, the wrapper $WMkT evaluates and takes apart the argument p,
+evaluates the argument t, and builds a three-field data value
+with the worker constructor MkT{v}. (There are more notes below
+about the unboxing of strict fields.) The worker $WMkT is called an implicit binding,
+because it's introduced implicitly by the data type declaration (record selectors
+are also implicit bindings, for example). Implicit bindings are injected into the code
+just before emitting code or External Core.
++After desugaring into Core (-ddump-ds), the definition of f looks like this: +
+ f x = case x of
+ Nil{d} -> Nil{v}
+ MkT{d} a b r -> let { p = (a,b); q = I# r } in
+ $WMkT p (q+1)
+
+Notice the way that pattern matching has been desugared to take account of the fact
+that the "real" data constructor MkT has three fields.
++By the time the simplifier has had a go at it, f will be transformed to: +
+ f x = case x of
+ Nil{d} -> Nil{v}
+ MkT{d} a b r -> MkT{v} a b (r +# 1#)
+
+Which is highly cool.
+
+
++ map MkT xs ++then $WMkT will not be inlined (because it is not applied to anything). +That is why we generate real top-level bindings for the wrapper functions, +and generate code for them. + + +
+ MkT{v} = \ p q r -> MkT{v} p q r
+
+This is a real hack. The occurrence on the RHS is saturated, so the code generator (both the
+one that generates abstract C and the byte-code generator) treats it as a special case and
+allocates a MkT; it does not make a recursive call! So now there's a top-level curried
+version of the worker which is available to anyone who wants it.
++This strange defintion is not emitted into External Core. Indeed, you might argue that +we should instead pass the list of TyCons to the code generator and have it +generate magic bindings directly. As it stands, it's a real hack: see the code in +CorePrep.mkImplicitBinds. + + +
+ data T a = MkT a a Int# | Nil{d}
+
+ $WMkT :: (a,a) -> T a -> T a
+ $WMkT p t = case p of
+ (a,b) -> seq t (MkT a b t)
+
+ f x = case x of
+ Nil -> Nil
+ MkT a b r -> MkT a b (r +# 1#)
+
+Notice that it makes perfect sense as a program all by itself. Constructors
+look like constructors (albeit not identical to the original Haskell ones).
++When reading in External Core, the parser is careful to read it back in just +as it was before it was spat out, namely: +
+ data T a = MkT{d} a a Int# | Nil{d}
+
+ $WMkT :: (a,a) -> T a -> T a
+ $WMkT p t = case p of
+ (a,b) -> seq t (MkT{v} a b t)
+
+ f x = case x of
+ Nil{d} -> Nil{v}
+ MkT{d} a b r -> MkT{v} a b (r +# 1#)
+
+
+
++ case e of + MkT p t -> ..p..t.. ++GHC will desugar this to the following Core code: +
+ case e of + MkT a b t -> let p = (a,b) in ..p..t.. ++The local let-binding reboxes the pair because it may be mentioned in +the case alternative. This may well be a bad idea, which is why +-funbox-strict-fields is an experimental feature. +
+It's essential that when importing a type T defined in some +external module M, GHC knows what representation was used for +that type, and that in turn depends on whether module M was +compiled with -funbox-strict-fields. So when writing an +interface file, GHC therefore records with each data type whether its +strict fields (if any) should be unboxed. + +
+Every data constructor Chas two info tables: +