[commit: ghc] master: Fix some typos in comments (3d80787)

git at git.haskell.org git at git.haskell.org
Thu Feb 13 19:56:31 UTC 2014


Repository : ssh://git@git.haskell.org/ghc

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/3d80787f8bd76015fbbcc127204bddc670f93872/ghc

>---------------------------------------------------------------

commit 3d80787f8bd76015fbbcc127204bddc670f93872
Author: Gabor Greif <ggreif at gmail.com>
Date:   Thu Feb 13 20:54:58 2014 +0100

    Fix some typos in comments


>---------------------------------------------------------------

3d80787f8bd76015fbbcc127204bddc670f93872
 compiler/coreSyn/CoreSubst.lhs     |    6 +++---
 compiler/specialise/SpecConstr.lhs |    2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/compiler/coreSyn/CoreSubst.lhs b/compiler/coreSyn/CoreSubst.lhs
index 7dfa25f..833f19e 100644
--- a/compiler/coreSyn/CoreSubst.lhs
+++ b/compiler/coreSyn/CoreSubst.lhs
@@ -1307,7 +1307,7 @@ Note [exprIsLiteral_maybe]
 
 This function will, given an expression `e`, try to turn it into the form
 `Lam v e'` (returned as `Just (v,e')`). Besides using lambdas, it looks through
-casts (using the Push rule), and it unfoldes function calls if the unfolding
+casts (using the Push rule), and it unfolds function calls if the unfolding
 has a greater arity than arguments are present.
 
 Currently, it is used in Rules.match, and is required to make
@@ -1321,7 +1321,7 @@ exprIsLambda_maybe :: InScopeEnv -> CoreExpr -> Maybe (Var, CoreExpr)
 exprIsLambda_maybe _ (Lam x e)
     = Just (x, e)
 
--- Also possible: A casted lambda. Push the coercion insinde
+-- Also possible: A casted lambda. Push the coercion inside
 exprIsLambda_maybe (in_scope_set, id_unf) (Cast casted_e co)
     | Just (x, e) <- exprIsLambda_maybe (in_scope_set, id_unf) casted_e
     -- Only do value lambdas.
@@ -1337,7 +1337,7 @@ exprIsLambda_maybe (in_scope_set, id_unf) e
     | (Var f, as) <- collectArgs e
     , let unfolding = id_unf f
     , Just rhs <- expandUnfolding_maybe unfolding
-    -- Make sure there is hope to get a lamda
+    -- Make sure there is hope to get a lambda
     , unfoldingArity unfolding > length (filter isValArg as)
     -- Optimize, for beta-reduction
     , let e' =  simpleOptExprWith (mkEmptySubst in_scope_set) (rhs `mkApps` as)
diff --git a/compiler/specialise/SpecConstr.lhs b/compiler/specialise/SpecConstr.lhs
index 060c705..86a56f4 100644
--- a/compiler/specialise/SpecConstr.lhs
+++ b/compiler/specialise/SpecConstr.lhs
@@ -335,7 +335,7 @@ I wonder if SpecConstr couldn't be extended to handle this? After all,
 lambda is a sort of constructor for functions and perhaps it already
 has most of the necessary machinery?
 
-Furthermore, there's an immediate win, because you don't need to allocate the lamda
+Furthermore, there's an immediate win, because you don't need to allocate the lambda
 at the call site; and if perchance it's called in the recursive call, then you
 may avoid allocating it altogether.  Just like for constructors.
 



More information about the ghc-commits mailing list