... | @@ -85,7 +85,7 @@ module N ( F (..) ) where |
... | @@ -85,7 +85,7 @@ module N ( F (..) ) where |
|
```
|
|
```
|
|
|
|
|
|
|
|
|
|
then `N` exports two different selectors with the `OccName``"foo"`. It might be enough to use `(OccName, Module)` instead of `(OccName, name)`, but I'm inclined to the latter in the interests of simplicity, and because otherwise we have to go to some trouble to avoid `gresFromAvails` outside the monad. In any case, if we want to allow two data family instances in the same module to use the same field name ([see below](records/overloaded-record-fields/implementation#data-families)), the module will not be enough.
|
|
then `N` exports two different selectors with the `OccName``"foo"`.
|
|
|
|
|
|
### `Parent` and `GlobalRdrElt`
|
|
### `Parent` and `GlobalRdrElt`
|
|
|
|
|
... | @@ -228,7 +228,7 @@ data instance F Bool = MkF2 { foo :: Bool } |
... | @@ -228,7 +228,7 @@ data instance F Bool = MkF2 { foo :: Bool } |
|
```
|
|
```
|
|
|
|
|
|
|
|
|
|
This is perfectly sensible, and should give rise to two \*different\* record selectors `foo`, and corresponding `Has` instances:
|
|
This is perfectly sensible, and gives rise to two \*different\* record selectors `foo`, and corresponding `Has` instances:
|
|
|
|
|
|
```wiki
|
|
```wiki
|
|
instance t ~ Int => Has (F Int) "foo" t
|
|
instance t ~ Int => Has (F Int) "foo" t
|
... | @@ -236,10 +236,10 @@ instance t ~ Bool => Has (F Bool) "foo" t |
... | @@ -236,10 +236,10 @@ instance t ~ Bool => Has (F Bool) "foo" t |
|
```
|
|
```
|
|
|
|
|
|
|
|
|
|
However, what can we call the record selectors? They can't both be `$sel_foo_F`! Ideally we would use the name of the representation tycon, rather than the family tycon, but that isn't introduced until the typechecker (`tcDataFamInstDecl` in `TcInstDcls`), and we need to create the selector in the renamer (`getLocalNonValBinders` in `RnNames`). We can't just pick an arbitrary unique name, because we need to look up the selector and dfuns/axioms later.
|
|
Thus we use the name of the representation tycon, rather than the family tycon, when naming the record selectors: we get `$sel_foo_R:FInt` and `$sel_foo_R:FBool`. This requires a bit of care, because lexically (in the `GlobalRdrEnv`) the selectors still have the family tycon are their parent.
|
|
|
|
|
|
|
|
|
|
For the moment, I've simply disallowed duplicate fields for a single data family in a single module. There are still problems if a field is duplicated for a single family across different modules. It's fine to duplicate fields between different data families, however.
|
|
In order to have access to the representation tycon name in the renamer, when the record selector names are generated, it is generated by `getLocalNonValBinders` and stored in a new field `dfid_rep_tycon` of `DataFamInstDecl`.
|
|
|
|
|
|
## Mangling selector names
|
|
## Mangling selector names
|
|
|
|
|
... | @@ -259,7 +259,6 @@ We could mangle selector names (using `$sel_foo_T` instead of `foo`) even when t |
... | @@ -259,7 +259,6 @@ We could mangle selector names (using `$sel_foo_T` instead of `foo`) even when t |
|
- When there is only one thing in scope, what should we do?
|
|
- When there is only one thing in scope, what should we do?
|
|
- Add `HsVarOut RdrName id` instead of `HsSingleRecFld` (or perhaps rename `HsVar` to `HsVarIn`); also useful to recall how the user referred to something.
|
|
- Add `HsVarOut RdrName id` instead of `HsSingleRecFld` (or perhaps rename `HsVar` to `HsVarIn`); also useful to recall how the user referred to something.
|
|
|
|
|
|
- What to do about data families with overloaded fields?
|
|
|
|
- Support virtual fields or forbid them?
|
|
- Support virtual fields or forbid them?
|
|
- Sort out reporting of unused imports.
|
|
- Sort out reporting of unused imports.
|
|
- Haddock omits fields from HTML index and prints selector names in LaTeX exports list.
|
|
- Haddock omits fields from HTML index and prints selector names in LaTeX exports list.
|
... | | ... | |