[Git][ghc/ghc][wip/int-index/visibility-check] Apply 7 suggestion(s) to 2 file(s)

[Vladislav Zavialov (@int-index)]

Vladislav Zavialov pushed to branch wip/int-index/visibility-check at Glasgow Haskell Compiler / GHC


Commits:
60cf227e by Ryan Scott at 2023-02-05T23:32:47+00:00
Apply 7 suggestion(s) to 2 file(s)
- - - - -


2 changed files:

- compiler/GHC/Core/TyCo/Compare.hs
- compiler/GHC/Tc/Utils/TcMType.hs


Changes:

=====================================
compiler/GHC/Core/TyCo/Compare.hs
=====================================
@@ -246,7 +246,7 @@ When we compare (ForAllTy (Bndr tv1 vis1) ty1)
 what should we do about `vis1` vs `vis2`?
 
 One option is to take those flags into account and check (vis1==vis2).
-But in Core visibility of forall-bound variables has no meaning,
+But in Core, the visibilities of forall-bound variables have no meaning,
 as type abstraction and type application are always explicit.
 Going to great lengths to carry them around is counterproductive,
 but not going far enough may lead to Core Lint errors (#22762).
@@ -255,13 +255,13 @@ The other option (the one we take) is to ignore those flags.
 Neither the name of a forall-bound variable nor its visibility flag
 affect GHC's notion of type equality.
 
-That said, in user-written programs visibility of foralls does matter
-a great deal. For example, if we unify tv := T, where
+That said, the visibilities of foralls do matter
+a great deal in user-written programs. For example, if we unify tv := T, where
   tv :: forall k.   k -> Type
   T  :: forall k -> k -> Type
-then the user can not substitute `T Maybe` for `tv Maybe` in their program
+then the user cannot substitute `T Maybe` for `tv Maybe` in their program
 by hand. They'd have to write `T (Type -> Type) Maybe` instead.
-This entails loss referential transparency. We solve this issue by
+This entails a loss of referential transparency. We solve this issue by
 checking the flags *outside* the equality relation. To that end,
 there are two ad-hoc checks:
   * checkEqForallVis (in checking mode)
@@ -271,8 +271,7 @@ These checks use `eqForAllVis` to compare the `ForAllTyFlag`s.
 But should we perhaps use (==) instead?
 Do we only care about visibility (Required vs Invisible)
 or do we also care about specificity (Specified vs Inferred)?
-
-Should GHC type-check the following program (adapted from #15740)?
+For example, should GHC type-check the following program (adapted from #15740)?
 
   {-# LANGUAGE PolyKinds, ... #-}
   data D a


=====================================
compiler/GHC/Tc/Utils/TcMType.hs
=====================================
@@ -614,7 +614,7 @@ tc_infer mb_frr tc_check
 *                                                                      *
 ********************************************************************* -}
 
--- Check if two presumably equal types actually differ in visibility
+-- Check if two presumably equal types actually differ in the visibility
 -- of their foralls. Example (from #18863):
 --
 --   type IDa :: forall i -> i -> Type
@@ -630,7 +630,7 @@ checkEqForallVis ty1 (Check ty2) =
     addErr $ TcRnIncompatibleForallVisibility ty1 ty2
 
 -- Structurally match two presumably equal types, checking that all pairs of
--- foralls have equal visibility.
+-- foralls have equal visibilities.
 --
 -- See Note [Presumably equal types]
 tcEqForallVis :: Type -> Type -> Bool



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/60cf227ee77c7bbf18e53fccb593368882ad3b2e

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/60cf227ee77c7bbf18e53fccb593368882ad3b2e
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230205/f0547555/attachment-0001.html>