Commit 78c80c25 authored by Gabor Greif's avatar Gabor Greif 💬
Browse files

Typos in comments and manual [ci skip]

parent 87c5fdbb
......@@ -1052,7 +1052,7 @@ dataConInstSig
-> [Type] -- Instantiate the *universal* tyvars with these types
-> ([TyVar], ThetaType, [Type]) -- Return instantiated existentials
-- theta and arg tys
-- ^ Instantantiate the universal tyvars of a data con,
-- ^ Instantiate the universal tyvars of a data con,
-- returning the instantiated existentials, constraints, and args
dataConInstSig (MkData { dcUnivTyVars = univ_tvs, dcExTyVars = ex_tvs
, dcEqSpec = eq_spec, dcOtherTheta = theta
......@@ -317,7 +317,7 @@ do so; it improves some programs significantly, and increasing convergence
isn't a bad thing. Hence the ABot/ATop in ArityType.
So these two transformations aren't always the Right Thing, and we
have several tickets reporting unexpected bahaviour resulting from
have several tickets reporting unexpected behaviour resulting from
this transformation. So we try to limit it as much as possible:
(1) Do NOT move a lambda outside a known-bottom case expression
......@@ -4100,7 +4100,7 @@ impliedXFlags
-- * utils/mkUserGuidePart/Options/
-- * docs/users_guide/using.rst
-- The first contains the Flag Refrence section, which breifly lists all
-- The first contains the Flag Reference section, which briefly lists all
-- available flags. The second contains a detailed description of the
-- flags. Both places should contain information whether a flag is implied by
-- -O0, -O or -O2.
......@@ -900,7 +900,7 @@ In some cases we want to deeply instantiate before filling in
an InferResult, and in some cases not. That's why InferReult
has the ir_inst flag.
* ir_inst = True: deeply instantantiate
* ir_inst = True: deeply instantiate
f x = (*)
......@@ -920,7 +920,7 @@ has the ir_inst flag.
Here want to instantiate f's type so that the ?x::Int constraint
gets discharged by the enclosing implicit-parameter binding.
* ir_inst = False: do not instantantiate
* ir_inst = False: do not instantiate
Consider this (which uses visible type application):
......@@ -12268,7 +12268,7 @@ If we did it in Haskell source, thus ::
let f = ... in f `seq` body
then ``f``\ 's polymorphic type would get intantiated, so the Core
then ``f``\ 's polymorphic type would get instantiated, so the Core
translation would be ::
let f = ... in f Any `seq` body
......@@ -51,7 +51,7 @@ import qualified Control.Monad.Fail as Fail
-- by @s@, and returns a value of type @a@.
-- The @s@ parameter is either
-- * an unstantiated type variable (inside invocations of 'runST'), or
-- * an uninstantiated type variable (inside invocations of 'runST'), or
-- * 'RealWorld' (inside invocations of 'stToIO').
......@@ -6,7 +6,7 @@
-- how to achieve something similar to the old behavior. This is
-- preventing HSP (and by extension, happstack) from migrating to GHC
-- 7. I reported this earlier on the mailing lists, but I have further
-- simplied the test case here.
-- simplified the test case here.
{-# LANGUAGE TypeFamilies, MultiParamTypeClasses
, FlexibleContexts, FlexibleInstances, UndecidableInstances
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