[commit: ghc] master: Move a Note to the module that refers to it (122ba98)

git at git.haskell.org git at git.haskell.org
Fri Jun 22 12:11:45 UTC 2018


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

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/122ba98af22c2b016561433dfa55bbabba98d972/ghc

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

commit 122ba98af22c2b016561433dfa55bbabba98d972
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Fri Jun 22 13:10:48 2018 +0100

    Move a Note to the module that refers to it


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

122ba98af22c2b016561433dfa55bbabba98d972
 compiler/typecheck/TcSimplify.hs | 13 -------------
 compiler/typecheck/TcType.hs     | 13 +++++++++++++
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/compiler/typecheck/TcSimplify.hs b/compiler/typecheck/TcSimplify.hs
index c6e5a6e..4024098 100644
--- a/compiler/typecheck/TcSimplify.hs
+++ b/compiler/typecheck/TcSimplify.hs
@@ -1207,19 +1207,6 @@ sure to quantify over them.  This leads to several wrinkles:
   refrain from bogusly quantifying, in TcSimplify.decideMonoTyVars.  We
   report the error later, in TcBinds.chooseInferredQuantifiers.
 
-Note [Quantifying over equality constraints]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Should we quantify over an equality constraint (s ~ t)?  In general, we don't.
-Doing so may simply postpone a type error from the function definition site to
-its call site.  (At worst, imagine (Int ~ Bool)).
-
-However, consider this
-         forall a. (F [a] ~ Int) => blah
-Should we quantify over the (F [a] ~ Int)?  Perhaps yes, because at the call
-site we will know 'a', and perhaps we have instance  F [Bool] = Int.
-So we *do* quantify over a type-family equality where the arguments mention
-the quantified variables.
-
 Note [Growing the tau-tvs using constraints]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 (growThetaTyVars insts tvs) is the result of extending the set
diff --git a/compiler/typecheck/TcType.hs b/compiler/typecheck/TcType.hs
index 26fc9fe..092c5a1 100644
--- a/compiler/typecheck/TcType.hs
+++ b/compiler/typecheck/TcType.hs
@@ -2128,6 +2128,19 @@ Notice that
 
 See also TcTyDecls.checkClassCycles.
 
+Note [Quantifying over equality constraints]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Should we quantify over an equality constraint (s ~ t)?  In general, we don't.
+Doing so may simply postpone a type error from the function definition site to
+its call site.  (At worst, imagine (Int ~ Bool)).
+
+However, consider this
+         forall a. (F [a] ~ Int) => blah
+Should we quantify over the (F [a] ~ Int)?  Perhaps yes, because at the call
+site we will know 'a', and perhaps we have instance  F [Bool] = Int.
+So we *do* quantify over a type-family equality where the arguments mention
+the quantified variables.
+
 Note [Inheriting implicit parameters]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Consider this:



More information about the ghc-commits mailing list