... | ... | @@ -274,16 +274,8 @@ We could mangle selector names (using `$sel:foo:T` instead of `foo`) even when t |
|
|
|
|
|
## To do
|
|
|
|
|
|
- Add `HsVarOut RdrName id` instead of `HsSingleRecFld` (or perhaps rename `HsVar` to `HsVarIn`)?
|
|
|
|
|
|
- This would also be useful to recall how the user referred to something.
|
|
|
- Is it worth generating all the derived names early, to get rid of `tcg_dfun_n`?
|
|
|
|
|
|
- Where should `TcBuiltInSynFamily` live? Could it be a fixed enumeration?
|
|
|
- Is `TcInstDcls.tcFldInsts` correct in its use of `simplifyTop` and assuming there will be no `ev_binds`?
|
|
|
|
|
|
- Consider syntactic sugar for `Upd` constraints.
|
|
|
- Improve unsolved `Accessor p f` error message where `p` is something silly?
|
|
|
- Consider defaulting `Accessor p` to `p = (->)`, and defaulting `Has r "f" t` constraints where there is only one datatype with a field `f` in scope.
|
|
|
|
|
|
- Document the extension.
|
|
|
- Tidy up code, comment, remove unused imports. |
|
|
- We could add `HsVarOut RdrName id` instead of `HsSingleRecFld` (or perhaps rename `HsVar` to `HsVarIn`). This would also be useful to recall how the user referred to something.
|
|
|
- Add syntax for record projection? When we have explicit type application, one might be able to use `field @"foo"` or `getField @"foo"`. |