[Git][ghc/ghc][wip/jade/ast] Apply 1 suggestion(s) to 1 file(s)

Hassan Al-Awwadi (@hassan.awwadi) gitlab at gitlab.haskell.org
Fri Oct 4 09:18:55 UTC 2024



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


Commits:
bb2bb34e by Hassan Al-Awwadi at 2024-10-04T09:18:52+00:00
Apply 1 suggestion(s) to 1 file(s)

Co-authored-by: Rodrigo Mesquita <rodrigo.m.mesquita at gmail.com>
- - - - -


1 changed file:

- compiler/GHC/Hs/Type.hs


Changes:

=====================================
compiler/GHC/Hs/Type.hs
=====================================
@@ -1088,47 +1088,54 @@ also forbids them in types involved with `deriving`:
 *                                                                      *
 ************************************************************************
 
-Note [Lifecycle of an UpdFieldOcc]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-When we have an update to a field occurrence (UpdFieldOcc) of the form
-rec{ label = value }, its possible that what label refers to is ambiguous,
-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 account for this the UpdFieldOcc occurrence 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
+Note [Lifecycle of FieldOcc/UpdFieldOcc]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+When renaming a "record field update" (`some_record{ field = expr }`), the field
+occurrence may be ambiguous if there are multiple record types with that same
+field label in scope. Instead of failing, we may attempt to do type-directed
+disambiguation: if we typecheck the record field update, we can disambiguate
+the `field` based on the record and field type.
+
+In practice, this means an identifier of an update field occurrence
+(`UpdFieldOcc`) may have to go straight from `RdrName` to `Id`, since field
+ambiguity makes it impossible to construct a `Name` for the field.
+
+Since type-directed disambiguation is a GHC property rather than a property of
+the GHC-Haskell AST, we still parametrise an `UpdFieldOcc` occurrence by `IdP p`,
+but introduce a constructor `AmbiguousFieldOcc` in the `XXUpdFieldOcc` extension point.
+That is:
+
+    * `AmbiguousFieldOcc @GhcRn :: RdrName -> UpdFieldOcc`
+    * `UpdFieldOcc @GhcRn :: Name -> UpdFieldOcc`
 
-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.
+If the update field occurrence is ambiguous, the renamer will construct it with
+`AmbiguousFieldOcc`. Otherwise, it'll use `UpdFieldOcc` -- an unambiguous
+update field occurrence.
+
+In @GhcTc the `UpdFieldOcc` extension point is "deleted" since all field
+occurrences after type checking must be unambiguous.
+
+A `FieldOcc` is a field occurrence that /does not/ occur in a record update, c.f. `UpdFieldOcc`.
+Non-update field occurrences are always unambiguous.
 
 The lifecycle of an UpdFieldOcc is as follows
 * GhcPs:
-  * UpdFieldOcc noExtField (FieldOcc GhcPs)
-  * XUpdFieldOcc DataConCantHappen
+  - UpdFieldOcc noExtField (FieldOcc GhcPs)
+  - XUpdFieldOcc DataConCantHappen
 * GhcRn:
-  * UpdFieldOcc noExtField (FieldOCc GhcRn)
-  * XUpdFieldOcc AmbiguousFieldOcc
+  - UpdFieldOcc noExtField (FieldOCc GhcRn)
+  - XUpdFieldOcc /AmbiguousFieldOcc/
 * GhcTc:
-  * UpdFieldOcc noExtField (FieldOCc GhcRn)
-  * XUpdFieldOcc DataConCantHappen
+  - UpdFieldOcc noExtField (FieldOCc GhcRn)
+  - XUpdFieldOcc DataConCantHappen
+
+The lifecycle of a FieldOcc is more straightforward:
+* GhcPs: FieldOcc noExtField RdrName
+* GhcRn: FieldOcc RdrName    Name
+* GhcTc: FieldOcc RdrName    Id
 
-so using DataConCantHappen we statically guarantee that when we go to a
-UpdFieldOcc GhcRn to UpdFieldOcc GhcTc we either succesfully disambiguate or
-error when we can't.
+NB: FieldOcc preserves the RdrName throughout its lifecycle for
+exact printing purposes.
 -}
 
 -- | Ambiguous Field Occurrence



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

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/bb2bb34e6b07d1dd75330ed6d8dfd25d48a6cf18
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/20241004/87612f3b/attachment-0001.html>


More information about the ghc-commits mailing list