[commit: ghc] master: Typos in comments (4d8859c)

git at git.haskell.org git at git.haskell.org
Mon Aug 3 12:26:27 UTC 2015


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

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/4d8859cc6302b89c81de9b6e4af241527c8fe716/ghc

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

commit 4d8859cc6302b89c81de9b6e4af241527c8fe716
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Mon Aug 3 11:04:22 2015 +0100

    Typos in comments


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

4d8859cc6302b89c81de9b6e4af241527c8fe716
 compiler/basicTypes/Demand.hs | 2 +-
 compiler/stranal/DmdAnal.hs   | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/compiler/basicTypes/Demand.hs b/compiler/basicTypes/Demand.hs
index bd2924a..8ee0f13 100644
--- a/compiler/basicTypes/Demand.hs
+++ b/compiler/basicTypes/Demand.hs
@@ -1214,7 +1214,7 @@ splitDmdTy ty@(DmdType _ [] res_ty)       = (resTypeArgDmd res_ty, ty)
 -- what of this demand should we consider, given that the IO action can cleanly
 -- exit?
 -- * We have to kill all strictness demands (i.e. lub with a lazy demand)
--- * We can keep demand information (i.e. lub with an absent deman)
+-- * We can keep demand information (i.e. lub with an absent demand)
 -- * We have to kill definite divergence
 -- * We can keep CPR information.
 -- See Note [IO hack in the demand analyser]
diff --git a/compiler/stranal/DmdAnal.hs b/compiler/stranal/DmdAnal.hs
index 8b97b6b..5836bfd 100644
--- a/compiler/stranal/DmdAnal.hs
+++ b/compiler/stranal/DmdAnal.hs
@@ -342,7 +342,7 @@ dmdAnalAlt env dmd case_bndr (con,bndrs,rhs)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 There's a hack here for I/O operations.  Consider
      case foo x s of { (# s, r #) -> y }
-Is this strict in 'y'.  Normally yes, but what if 'foo' is an I/O
+Is this strict in 'y'?  Normally yes, but what if 'foo' is an I/O
 operation that simply terminates the program (not in an erroneous way)?
 In that case we should not evaluate 'y' before the call to 'foo'.
 Hackish solution: spot the IO-like situation and add a virtual branch,
@@ -365,14 +365,14 @@ However, consider
 Here it is terribly sad to make 'f' lazy in 's'.  After all,
 getMaskingState# is not going to diverge or throw an exception!  This
 situation actually arises in GHC.IO.Handle.Internals.wantReadableHandle
-(on an MVar not an Int), and make a material difference.
+(on an MVar not an Int), and made a material difference.
 
 So if the scrutinee is a primop call, we *don't* apply the
 state hack:
   - If is a simple, terminating one like getMaskingState,
     applying the hack is over-conservative.
   - If the primop is raise# then it returns bottom, so
-    the case alternatives are alraedy discarded.
+    the case alternatives are already discarded.
   - If the primop can raise a non-IO exception, like
     divide by zero or seg-fault (eg writing an array
     out of bounds) then we don't mind evaluating 'x' first.



More information about the ghc-commits mailing list