summaryrefslogtreecommitdiff
path: root/compiler/rename
diff options
context:
space:
mode:
authorGabor Greif <ggreif@gmail.com>2014-01-26 13:39:00 +0100
committerGabor Greif <ggreif@gmail.com>2014-01-26 14:03:51 +0100
commit9005f91e2884b0db1f8b66b124708f65f7e69b90 (patch)
treedc7b694d55c3201b7946fcb3058a31289dff3913 /compiler/rename
parent5281dd6f5998af94aa06c3769089db7011ea4463 (diff)
downloadhaskell-9005f91e2884b0db1f8b66b124708f65f7e69b90.tar.gz
Squash some spelling issues
Diffstat (limited to 'compiler/rename')
-rw-r--r--compiler/rename/RnEnv.lhs4
-rw-r--r--compiler/rename/RnPat.lhs4
-rw-r--r--compiler/rename/RnSource.lhs2
3 files changed, 5 insertions, 5 deletions
diff --git a/compiler/rename/RnEnv.lhs b/compiler/rename/RnEnv.lhs
index 1028d08f03..f0d1840970 100644
--- a/compiler/rename/RnEnv.lhs
+++ b/compiler/rename/RnEnv.lhs
@@ -450,7 +450,7 @@ Thus:
data G a
instance C S where
data G S = Y1 | Y2
-Even though there are two G's in scope (M.G and Blib.G), the occurence
+Even though there are two G's in scope (M.G and Blib.G), the occurrence
of 'G' in the 'instance C S' decl is unambiguous, because C has only
one associated type called G. This is exactly what happens for methods,
and it is only consistent to do the same thing for types. That's the
@@ -611,7 +611,7 @@ When the user writes:
'Zero' in the type signature of 'foo' is parsed as:
HsTyVar ("Zero", TcClsName)
-When the renamer hits this occurence of 'Zero' it's going to realise
+When the renamer hits this occurrence of 'Zero' it's going to realise
that it's not in scope. But because it is renaming a type, it knows
that 'Zero' might be a promoted data constructor, so it will demote
its namespace to DataName and do a second lookup.
diff --git a/compiler/rename/RnPat.lhs b/compiler/rename/RnPat.lhs
index 639ab51101..3fde563cd3 100644
--- a/compiler/rename/RnPat.lhs
+++ b/compiler/rename/RnPat.lhs
@@ -153,7 +153,7 @@ Consider
g _ = T1
-Arguaby we should report T2 as unused, even though it appears in a
+Arguably we should report T2 as unused, even though it appears in a
pattern, because it never occurs in a constructed position. See
Trac #7336.
However, implementing this in the face of pattern synonyms would be
@@ -166,7 +166,7 @@ we need to observe the dependency between P1 and P2 so that type
checking can be done in the correct order (just like for value
bindings). Dependencies between bindings is analyzed in the renamer,
where we don't know yet whether P2 is a constructor or a pattern
-synonym. So for now, we do report conid occurances in patterns as
+synonym. So for now, we do report conid occurrences in patterns as
uses.
%*********************************************************
diff --git a/compiler/rename/RnSource.lhs b/compiler/rename/RnSource.lhs
index f3b4d9178d..c726d554fc 100644
--- a/compiler/rename/RnSource.lhs
+++ b/compiler/rename/RnSource.lhs
@@ -60,7 +60,7 @@ for undefined tyvars, and tyvars in contexts that are ambiguous.
(Some of this checking has now been moved to module @TcMonoType@,
since we don't have functional dependency information at this point.)
\item
-Checks that all variable occurences are defined.
+Checks that all variable occurrences are defined.
\item
Checks the @(..)@ etc constraints in the export list.
\end{enumerate}