... | @@ -239,7 +239,13 @@ instance t ~ Bool => Has (F Bool) "foo" t |
... | @@ -239,7 +239,13 @@ instance t ~ Bool => Has (F Bool) "foo" t |
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
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`.
|
|
In order to have access to the representation tycon name in the renamer, it is generated by `getLocalNonValBinders` and stored in a new field `dfid_rep_tycon` of `DataFamInstDecl`. It would be nice if we could do the same for all the derived names, in order to localise the set of names that have been used (currently stored in the `tcg_dfun_n` mutable field). However, this is tricky:
|
|
|
|
|
|
|
|
- Default associated type declarations result in axioms being generated during typechecking.
|
|
|
|
- DFun names for instances of `Typeable` and the `Generics` classes are generated during typechecking.
|
|
|
|
|
|
|
|
|
|
|
|
We could work around this but it may not be worth the bother.
|
|
|
|
|
|
## Mangling selector names
|
|
## Mangling selector names
|
|
|
|
|
... | | ... | |