[Git][ghc/ghc][wip/jade/ast] 2 commits: More renaming.

[Hassan Al-Awwadi (@hassan.awwadi)]

Hassan Al-Awwadi pushed to branch wip/jade/ast at Glasgow Haskell Compiler / GHC


Commits:
c0165aa0 by Hassan Al-Awwadi at 2024-10-01T15:33:37+02:00
More renaming.

- - - - -
1741c6cf by Hassan Al-Awwadi at 2024-10-01T16:00:19+02:00
updated note

- - - - -


2 changed files:

- compiler/GHC/Hs/Type.hs
- utils/check-exact/ExactPrint.hs


Changes:

=====================================
compiler/GHC/Hs/Type.hs
=====================================
@@ -1088,32 +1088,47 @@ also forbids them in types involved with `deriving`:
 *                                                                      *
 ************************************************************************
 
-Note [Lifecycle of a FieldOcc]
+Note [Lifecycle of an UpdFieldOcc]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-A field occurrence (FieldOcc) has a slightly special lifecycle because field
-occurrences may be deemed /ambiguous/ during renaming. Ambiguous field
-occurrences can only be resolved during typechecking (since we do type-directed
-disambiguation). To accommodate the fact that we may be unable to produce a
-`Name` for a `FieldOcc` during renaming, `FieldOcc` is extended with
-`AmbiguousFieldOcc` during renaming. Here's the life cycle:
-
-* The `FieldOcc` constructor of the `FieldOcc` type always refers to an
-  unambiguous field occurrence. We parse field occurrences into `FieldOcc`.
-
-* During renaming, a FieldOcc may be ambiguous and only be resolvable
-  during typechecking. To construct an /ambiguous/ `FieldOcc GhcRn`, we use the
-  extension point for constructors, which is instanced with `AmbiguousFieldOcc`:
-
-    (XFieldOcc . Ambiguous) :: FieldOcc GhcRn
-
-* During typechecking, all ambiguous field occurrences must be resolved. We
-  statically guarantee this by making it impossible to construct a `FieldOcc
-  GhcTc` with an ambiguous name:
-
-    type instance XXFieldOcc GhcTc = DataConCantHappen
-
-Note that throughout this lifecycle, we preserve the `RdrName` the user
-originally wrote in the extension point during renaming and typechecking.
+When we have an update to a field occurance (UpdFieldOcc) of the form 
+rec{ label = value }, its possible that what label refers to is ambigious, 
+aka: that there are multiple record types with label as a field. In this case
+we can't go from a RdrName in the GhcPs stage to a Name in the GhcRn stage, 
+because we have multiple Names we could choose from. Once we typecheck, we 
+also do type-directed disambiguation, so at that stage we can go directly from 
+a Name to an Id, modulo the disambiguation succeeding.  
+
+To accound for this the UpdFieldOcc occurence has an instantiation for its
+XXUpdFieldOcc type family: AmbiguousFieldOcc. AmbiguousFieldOcc just stores 
+the RdrName directly, whereas the FieldOcc (GhcPass p) field will go from 
+RdrName to Name to Id as the stage shifts. Note that FieldOcc also stores
+the RdrName throughout its lifecycle, for exact printing purpose, after the 
+Parse stage this RdrName just shifts from the foLabel field to the foExt field.
+
+Summarised the lifecycle of a FieldOcc is like this: 
+* GhcPs: FieldOcc noExtField RdrName 
+* GhcRn: FieldOcc RdrName    Name 
+* GhcTc: FieldOcc RdrName    Id 
+
+With its extra constructor `XFieldOcc currently being unused and disabled by 
+instantiation XXFieldOcc (GhcPass p) = DataConCantHappen. In most cases just 
+having this FieldOcc datatype is enough, but as mentioned the UpdFieldOcc case 
+requires a case for ambiguity.
+
+The lifecycle of an UpdFieldOcc is as follows
+* GhcPs:
+  * UpdFieldOcc noExtField (FieldOcc GhcPs)
+  * XUpdFieldOcc DataConCantHappen
+* GhcRn:
+  * UpdFieldOcc noExtField (FieldOCc GhcRn)
+  * XUpdFieldOcc AmbiguousFieldOcc
+* GhcTc:
+  * UpdFieldOcc noExtField (FieldOCc GhcRn)
+  * XUpdFieldOcc DataConCantHappen
+
+so using DataConCantHappen we statically guarentee that when we go to a
+UpdFieldOcc GhcRn to UpdFieldOcc GhcTc we either succesfully disambiguate or 
+error when we can't. 
 -}
 
 -- | Ambiguous Field Occurrence
@@ -1124,7 +1139,8 @@ originally wrote in the extension point during renaming and typechecking.
 -- originally wrote, and store the selector function after the typechecker (for
 -- ambiguous occurrences).
 --
--- Unambiguous field occurrences should be stored in the proper FieldOcc datacon of FieldOcc.
+-- Unambiguous field occurrences should be stored in the proper
+-- UpdFieldOcc datacon of UpdFieldOcc.
 --
 -- See Note [HsRecField and HsRecUpdField] in "GHC.Hs.Pat".
 -- See Note [Located RdrNames] in "GHC.Hs.Expr".


=====================================
utils/check-exact/ExactPrint.hs
=====================================
@@ -3507,7 +3507,7 @@ instance (ExactPrint body)
 -- ---------------------------------------------------------------------
 
 instance (ExactPrint (LocatedA body))
-    => ExactPrint (HsFieldBind (LocatedA (AmbiguousFieldOcc GhcPs)) (LocatedA body)) where
+    => ExactPrint (HsFieldBind (LocatedA (UpdFieldOcc GhcPs)) (LocatedA body)) where
   getAnnotationEntry _ = NoEntryVal
   setAnnotationAnchor a _ _ _ = a
 



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/69e564bf991d6188cfa021c837d4e2c747e9b38a...1741c6cf917707c4126b77ef05eb7f6d6ab173d9

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/69e564bf991d6188cfa021c837d4e2c747e9b38a...1741c6cf917707c4126b77ef05eb7f6d6ab173d9
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/20241001/52f39e1b/attachment-0001.html>