Commit 61995883 authored by Gabor Greif's avatar Gabor Greif 💬

More typos in comments [skip ci]

parent 4e7d8350
......@@ -598,7 +598,7 @@ Terminology:
Note [Data con representation]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The dcRepType field contains the type of the representation of a contructor
The dcRepType field contains the type of the representation of a constructor
This may differ from the type of the constructor *Id* (built
by MkId.mkDataConId) for two reasons:
a) the constructor Id may be overloaded, but the dictionary isn't stored
......
......@@ -894,7 +894,7 @@ CPRResult: NoCPR
RetProd RetSum ConTag
Product contructors return (Dunno (RetProd rs))
Product constructors return (Dunno (RetProd rs))
In a fixpoint iteration, start from Diverges
We have lubs, but not glbs; but that is ok.
-}
......
......@@ -497,7 +497,7 @@ mkDataConRep dflags fam_envs wrap_name mb_bangs data_con
-- The Cpr info can be important inside INLINE rhss, where the
-- wrapper constructor isn't inlined.
-- And the argument strictness can be important too; we
-- may not inline a contructor when it is partially applied.
-- may not inline a constructor when it is partially applied.
-- For example:
-- data W = C !Int !Int !Int
-- ...(let w = C x in ...(w p q)...)...
......
......@@ -292,7 +292,7 @@ mkLFImported id
-- Dynamic pointer tagging
-----------------------------------------------------
type ConTagZ = Int -- A *zero-indexed* contructor tag
type ConTagZ = Int -- A *zero-indexed* constructor tag
type DynTag = Int -- The tag on a *pointer*
-- (from the dynamic-tagging paper)
......
......@@ -714,7 +714,7 @@ missed the first one.)
combineIdenticalAlts :: [AltCon] -- Constructors that cannot match DEFAULT
-> [CoreAlt]
-> (Bool, -- True <=> something happened
[AltCon], -- New contructors that cannot match DEFAULT
[AltCon], -- New constructors that cannot match DEFAULT
[CoreAlt]) -- New alternatives
-- See Note [Combine identical alternatives]
-- True <=> we did some combining, result is a single DEFAULT alternative
......@@ -2118,7 +2118,7 @@ rhsIsStatic :: Platform
-- This is a bit like CoreUtils.exprIsHNF, with the following differences:
-- a) scc "foo" (\x -> ...) is updatable (so we catch the right SCC)
--
-- b) (C x xs), where C is a contructor is updatable if the application is
-- b) (C x xs), where C is a constructor is updatable if the application is
-- dynamic
--
-- c) don't look through unfolding of f in (f x).
......
......@@ -1793,7 +1793,7 @@ implicitTyConThings tc
implicitCoTyCon tc ++
-- for each data constructor in order,
-- the contructor, worker, and (possibly) wrapper
-- the constructor, worker, and (possibly) wrapper
[ thing | dc <- tyConDataCons tc
, thing <- AConLike (RealDataCon dc) : dataConImplicitTyThings dc ]
-- NB. record selectors are *not* implicit, they have fully-fledged
......
......@@ -1728,7 +1728,7 @@ rnDataDefn doc (HsDataDefn { dd_ND = new_or_data, dd_cType = cType
badGadtStupidTheta :: HsDocContext -> SDoc
badGadtStupidTheta _
= vcat [text "No context is allowed on a GADT-style data declaration",
text "(You can put a context on each contructor, though.)"]
text "(You can put a context on each constructor, though.)"]
rnFamDecl :: Maybe Name -- Just cls => this FamilyDecl is nested
-- inside an *class decl* for cls
......
......@@ -1507,7 +1507,7 @@ type GlobalScruts = IdSet -- See Note [Binder swap on GlobalId scrutinees]
-- y = /\a -> (p a, q a) -- Still don't inline p or q
-- z = f (p,q) -- Do inline p,q; it may make a rule fire
-- So OccEncl tells enought about the context to know what to do when
-- we encounter a contructor application or PAP.
-- we encounter a constructor application or PAP.
data OccEncl
= OccRhs -- RHS of let(rec), albeit perhaps inside a type lambda
......
......@@ -2645,7 +2645,7 @@ Rather than do this we simply agree to re-simplify the original (small) thing la
Note [Funky mkLamTypes]
~~~~~~~~~~~~~~~~~~~~~~
Notice the funky mkLamTypes. If the contructor has existentials
Notice the funky mkLamTypes. If the constructor has existentials
it's possible that the join point will be abstracted over
type variables as well as term variables.
Example: Suppose we have
......
......@@ -695,7 +695,7 @@ data TcLclEnv -- Changes as we move inside an expression
-- Does *not* include global name envt; may shadow it
-- Includes both ordinary variables and type variables;
-- they are kept distinct because tyvar have a different
-- occurrence contructor (Name.TvOcc)
-- occurrence constructor (Name.TvOcc)
-- We still need the unsullied global name env so that
-- we can look up record field names
......
......@@ -329,7 +329,7 @@ A FamInstEnv maps a family name to the list of known instances for that family.
The same FamInstEnv includes both 'data family' and 'type family' instances.
Type families are reduced during type inference, but not data families;
the user explains when to use a data family instance by using contructors
the user explains when to use a data family instance by using constructors
and pattern matching.
Nevertheless it is still useful to have data families in the FamInstEnv:
......
......@@ -215,7 +215,7 @@ See also Note [Wrappers for data instance tycons] in MkId.hs
* The axiom ax_ti may be eta-reduced; see
Note [Eta reduction for data family axioms] in TcInstDcls
* The data contructor T2 has a wrapper (which is what the
* The data constructor T2 has a wrapper (which is what the
source-level "T2" invokes):
$WT2 :: Bool -> T Int
......
......@@ -22,7 +22,7 @@
Building Haskell objects from C datatypes.
TODO: Currently this code does not tag created pointers,
however it is not unsafe (the contructor code will do it)
however it is not unsafe (the constructor code will do it)
just inefficient.
------------------------------------------------------------------------- */
HaskellObj
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment