summaryrefslogtreecommitdiff
path: root/compiler/GHC/Utils/Monad.hs
diff options
context:
space:
mode:
authorRyan Scott <ryan.gl.scott@gmail.com>2020-07-05 16:15:01 -0400
committerMarge Bot <ben+marge-bot@smart-cactus.org>2020-11-06 03:45:28 -0500
commite07e383a3250cb27a9128ad8d5c68def5c3df336 (patch)
treeb580fd84319138a3508303356318ac9b78750009 /compiler/GHC/Utils/Monad.hs
parent2125b1d6bea0c620e3a089603dace6bb38020c81 (diff)
downloadhaskell-e07e383a3250cb27a9128ad8d5c68def5c3df336.tar.gz
Replace HsImplicitBndrs with HsOuterTyVarBndrs
This refactors the GHC AST to remove `HsImplicitBndrs` and replace it with `HsOuterTyVarBndrs`, a type which records whether the outermost quantification in a type is explicit (i.e., with an outermost, invisible `forall`) or implicit. As a result of this refactoring, it is now evident in the AST where the `forall`-or-nothing rule applies: it's all the places that use `HsOuterTyVarBndrs`. See the revamped `Note [forall-or-nothing rule]` in `GHC.Hs.Type` (previously in `GHC.Rename.HsType`). Moreover, the places where `ScopedTypeVariables` brings lexically scoped type variables into scope are a subset of the places that adhere to the `forall`-or-nothing rule, so this also makes places that interact with `ScopedTypeVariables` easier to find. See the revamped `Note [Lexically scoped type variables]` in `GHC.Hs.Type` (previously in `GHC.Tc.Gen.Sig`). `HsOuterTyVarBndrs` are used in type signatures (see `HsOuterSigTyVarBndrs`) and type family equations (see `HsOuterFamEqnTyVarBndrs`). The main difference between the former and the latter is that the former cares about specificity but the latter does not. There are a number of knock-on consequences: * There is now a dedicated `HsSigType` type, which is the combination of `HsOuterSigTyVarBndrs` and `HsType`. `LHsSigType` is now an alias for an `XRec` of `HsSigType`. * Working out the details led us to a substantial refactoring of the handling of explicit (user-written) and implicit type-variable bindings in `GHC.Tc.Gen.HsType`. Instead of a confusing family of higher order functions, we now have a local data type, `SkolemInfo`, that controls how these binders are kind-checked. It remains very fiddly, not fully satisfying. But it's better than it was. Fixes #16762. Bumps the Haddock submodule. Co-authored-by: Simon Peyton Jones <simonpj@microsoft.com> Co-authored-by: Richard Eisenberg <rae@richarde.dev> Co-authored-by: Zubin Duggal <zubin@cmi.ac.in>
Diffstat (limited to 'compiler/GHC/Utils/Monad.hs')
-rw-r--r--compiler/GHC/Utils/Monad.hs7
1 files changed, 7 insertions, 0 deletions
diff --git a/compiler/GHC/Utils/Monad.hs b/compiler/GHC/Utils/Monad.hs
index 8ba0eefb34..19b0667ceb 100644
--- a/compiler/GHC/Utils/Monad.hs
+++ b/compiler/GHC/Utils/Monad.hs
@@ -11,6 +11,7 @@ module GHC.Utils.Monad
, zipWith3M, zipWith3M_, zipWith4M, zipWithAndUnzipM
, mapAndUnzipM, mapAndUnzip3M, mapAndUnzip4M, mapAndUnzip5M
, mapAccumLM
+ , liftFstM, liftSndM
, mapSndM
, concatMapM
, mapMaybeM
@@ -164,6 +165,12 @@ mapSndM f xs = go xs
go [] = return []
go ((a,b):xs) = do { c <- f b; rs <- go xs; return ((a,c):rs) }
+liftFstM :: Monad m => (a -> b) -> m (a, r) -> m (b, r)
+liftFstM f thing = do { (a,r) <- thing; return (f a, r) }
+
+liftSndM :: Monad m => (a -> b) -> m (r, a) -> m (r, b)
+liftSndM f thing = do { (r,a) <- thing; return (r, f a) }
+
-- | Monadic version of concatMap
concatMapM :: Monad m => (a -> m [b]) -> [a] -> m [b]
concatMapM f xs = liftM concat (mapM f xs)