|
|
# To discuss
|
|
|
|
|
|
- How to fix [\#11719](https://gitlab.haskell.org//ghc/ghc/issues/11719). We can't ever infer a type variable to have a higher-rank kind (as would seem necessary in this example). But perhaps we should type-check type patterns in a different manner than ordinary types, just like `tcPat` is distinct from `tcExpr`. Then, we could use bidirectional type-checking to get things to work out. This is a pretty significant refactor, though. Is it worth it? Or do we just wait until we have dependent types?
|
|
|
Tasks discussed by Richard and Simon. This page is mostly for our own notes, but others are welcome to read it.
|
|
|
|
|
|
# Summary of tasks to be completed
|
|
|
# Roadmap of new stuff we want to get done
|
|
|
|
|
|
|
|
|
Tasks discussed by Richard and Simon. This page is mostly for our own notes, but others are welcome to read it.
|
|
|
These things are all either new features, or significant refactorings. All aimed at "filling out" what Haskell does to be simple and consistent.
|
|
|
|
|
|
|
|
|
Nov 18
|
|
|
We should be clear about the dependencies between items on this list.
|
|
|
|
|
|
- [\#15977](https://gitlab.haskell.org//ghc/ghc/issues/15977): restructure typechecking modules
|
|
|
- [ Proposal 81: Visible dependent quantification](https://github.com/ghc-proposals/ghc-proposals/pull/81). Just syntax! Lets you say `forall a -> ty` in types. See [GhcKinds/KindInference](ghc-kinds/kind-inference) and [GhcKinds/KindInference/Examples](ghc-kinds/kind-inference/examples).
|
|
|
|
|
|
- [ Proposal 99: explicit specificity](https://github.com/ghc-proposals/ghc-proposals/pull/99). Lets us write `T :: forall {k} (a :: k).blah`.
|
|
|
|
|
|
Oct 18: (SLPJ note Nov 18: I think all this is done as part of the Monster Kind Patch)
|
|
|
- [ Proposal 179: tweak printing of foralls](https://github.com/ghc-proposals/ghc-proposals/pull/179)
|
|
|
|
|
|
- New module `KcTyClsDecls` that pulls from `TcTyClsDecls` and `TcHsType`.
|
|
|
- Remove `get_class_tvs` from `kcTyClGroup`, in favor of tracking AT TcTyCons in the class TcTyCon
|
|
|
- Remove all the work in `tcTyClTyVars`. It's redundant. `correct_binders` is done by `mk_req_tcb` in `generalise`, `reportFloatingKvs` is irrelevant for CUSKS (should move to `generalise` or `checkValidTyCon`), and `findDupTyVarTvs` can move to `generalise`.
|
|
|
- [ Proposal 54: top-level kind signatures for type constuctors](https://github.com/ghc-proposals/ghc-proposals/pull/54) (depends on Proposal 81)
|
|
|
|
|
|
- [ Proposal 103: treat kind and type variables identically in forall](https://github.com/ghc-proposals/ghc-proposals/pull/103) (depends on Proposal 83). Includes applying the "forall-or-nothing rule" to kind variables. The proposal says "wait until two releases after Proposal 83 is done (which was in 8.6)". So we can do this in HEAD as soon as 8.8 forks. Subsumes [\#14548](https://gitlab.haskell.org//ghc/ghc/issues/14548).
|
|
|
|
|
|
Aug 18:
|
|
|
- [\#12088](https://gitlab.haskell.org//ghc/ghc/issues/12088): SCC for kind inference: we know what to do, it's just a question of doing it. See also [\#7503](https://gitlab.haskell.org//ghc/ghc/issues/7503), [\#14451](https://gitlab.haskell.org//ghc/ghc/issues/14451). This will be much easier once Proposal 54 is done.
|
|
|
|
|
|
- [\#15743](https://gitlab.haskell.org//ghc/ghc/issues/15743): nail down inferred/specified/required
|
|
|
- [\#15497](https://gitlab.haskell.org//ghc/ghc/issues/15497): coercion quantification and [ Phab:D5054](https://phabricator.haskell.org/D5054)
|
|
|
- [\#15621](https://gitlab.haskell.org//ghc/ghc/issues/15621), [\#14185](https://gitlab.haskell.org//ghc/ghc/issues/14185): using implication constraints to improve error messages
|
|
|
- [\#15579](https://gitlab.haskell.org//ghc/ghc/issues/15579): `topNormaliseType`; also [\#14729](https://gitlab.haskell.org//ghc/ghc/issues/14729)
|
|
|
- `zonkPromote`: the remaining ones are there for a reason; but Simon still unhappy; see RAE/SLPJ Slack channel 31 Aug; and [\#15588](https://gitlab.haskell.org//ghc/ghc/issues/15588) and [\#15589](https://gitlab.haskell.org//ghc/ghc/issues/15589). Stuff about "fully-known type variables".
|
|
|
- [\#15479](https://gitlab.haskell.org//ghc/ghc/issues/15479): refactoring `tcHsType`
|
|
|
- [\#15577](https://gitlab.haskell.org//ghc/ghc/issues/15577): surprising coercions
|
|
|
- [\#14887](https://gitlab.haskell.org//ghc/ghc/issues/14887): telescopes
|
|
|
- [\#15474](https://gitlab.haskell.org//ghc/ghc/issues/15474): (small) `Any` etc.
|
|
|
- [ Proposal 126: Type applications in patterns](https://github.com/ghc-proposals/ghc-proposals/pull/126).
|
|
|
|
|
|
# Refactoring of existing stuff that we'd like to get done
|
|
|
|
|
|
July 18:
|
|
|
- [\#15977](https://gitlab.haskell.org//ghc/ghc/issues/15977): restructure typechecking modules. New module `KcTyClsDecls` that pulls from `TcTyClsDecls` and `TcHsType`.
|
|
|
- [\#14873](https://gitlab.haskell.org//ghc/ghc/issues/14873): make `typeKind` monadic in the type checker
|
|
|
- [\#15809](https://gitlab.haskell.org//ghc/ghc/issues/15809): use level numbers for generalisation
|
|
|
- [\#8095](https://gitlab.haskell.org//ghc/ghc/issues/8095): coercion zapping
|
|
|
|
|
|
- [\#14164](https://gitlab.haskell.org//ghc/ghc/issues/14164): comments, invariant, asserts (Richard)
|
|
|
- [\#14873](https://gitlab.haskell.org//ghc/ghc/issues/14873): make `typeKind` monadic in the type checker
|
|
|
- [\#15346](https://gitlab.haskell.org//ghc/ghc/issues/15346): `pushCoDataCon` is wrong somehow
|
|
|
- [\#15577](https://gitlab.haskell.org//ghc/ghc/issues/15577): surprising coercions: see comment:5
|
|
|
- [\#15621](https://gitlab.haskell.org//ghc/ghc/issues/15621), [\#14185](https://gitlab.haskell.org//ghc/ghc/issues/14185): using implication constraints to improve error messages
|
|
|
- [\#15579](https://gitlab.haskell.org//ghc/ghc/issues/15579): `topNormaliseType`; also [\#14729](https://gitlab.haskell.org//ghc/ghc/issues/14729)
|
|
|
- `zonkPromote`: the remaining ones are there for a reason; but Simon still unhappy; see RAE/SLPJ Slack channel 31 Aug; and [\#15588](https://gitlab.haskell.org//ghc/ghc/issues/15588), [\#15141](https://gitlab.haskell.org//ghc/ghc/issues/15141), and [\#15589](https://gitlab.haskell.org//ghc/ghc/issues/15589). Stuff about "fully-known type variables".
|
|
|
- [\#15474](https://gitlab.haskell.org//ghc/ghc/issues/15474): (small) `Any` etc.
|
|
|
- [\#15192](https://gitlab.haskell.org//ghc/ghc/issues/15192): `GRefl`: still looking into perf changes
|
|
|
- [\#8095](https://gitlab.haskell.org//ghc/ghc/issues/8095): coercion zapping
|
|
|
- Better floatEqualites based on level numbers
|
|
|
- Better floatEqualites based on level numbers?
|
|
|
|
|
|
**Type declarations and signatures** (Dec 17)
|
|
|
- [\#15479](https://gitlab.haskell.org//ghc/ghc/issues/15479): refactoring `tcHsType` (Simon is not 100% convinced)
|
|
|
|
|
|
- (May 18). Simon is very suspicious about `zonkPromote` and friends. Revisit this once we get rid of `decideKindGeneralisationPlan`. [\#15141](https://gitlab.haskell.org//ghc/ghc/issues/15141) is a good starting point.
|
|
|
# I'm unsure of the status of these things
|
|
|
|
|
|
- (May 18) [\#14040](https://gitlab.haskell.org//ghc/ghc/issues/14040), which I think is not fixed. But it’s somehow linked to [\#15076](https://gitlab.haskell.org//ghc/ghc/issues/15076). And that in turn is caused by [\#14880](https://gitlab.haskell.org//ghc/ghc/issues/14880). Which Richard has a patch for that doesn’t quite work yet. And the fix might cure [\#14887](https://gitlab.haskell.org//ghc/ghc/issues/14887)
|
|
|
|
|
|
- (May 18): [\#15122](https://gitlab.haskell.org//ghc/ghc/issues/15122)
|
|
|
|
|
|
- (May 18): [\#15142](https://gitlab.haskell.org//ghc/ghc/issues/15142): `getInitialKinds` simplification
|
|
|
|
|
|
- Let's fix [\#14880](https://gitlab.haskell.org//ghc/ghc/issues/14880)!
|
|
|
|
|
|
- `uo_thing`, [\#9173](https://gitlab.haskell.org//ghc/ghc/issues/9173), [\#13601](https://gitlab.haskell.org//ghc/ghc/issues/13601)
|
|
|
|
|
|
- [ Proposal 83: collapse PolyKinds and TypeInType](https://github.com/ghc-proposals/ghc-proposals/pull/83)
|
|
|
- [ Proposal 81: Visible dependent quantification](https://github.com/ghc-proposals/ghc-proposals/pull/81)
|
|
|
- [ Proposal 54: CUSKs (depends on Proposal 81)](https://github.com/ghc-proposals/ghc-proposals/pull/54)
|
|
|
- [ Proposal 103: treat kind and type variables identically in forall](https://github.com/ghc-proposals/ghc-proposals/pull/103) (depends on Proposal 83)
|
|
|
- Add curly-braces for scoping but no type application (nothing depends on this)
|
|
|
- Scoping only with explicit foralls (perhaps best after Proposal 83, because explicit kind-forall needs TypeInType). Subsumes [\#14548](https://gitlab.haskell.org//ghc/ghc/issues/14548).
|
|
|
- Fix [\#14451](https://gitlab.haskell.org//ghc/ghc/issues/14451) (SCC analysis of type declarations)
|
|
|
- All or nothing rule applies to kind variables too (edited)
|
|
|
|
|
|
**Big things**
|
|
|
|
|
|
- Homogeneous flattener ([\#12919](https://gitlab.haskell.org//ghc/ghc/issues/12919), [\#13643](https://gitlab.haskell.org//ghc/ghc/issues/13643)). [ Phab:D3848](https://phabricator.haskell.org/D3848). [ Phab:D4451](https://phabricator.haskell.org/D4451) is a patch to D3848 that fixes performance
|
|
|
- [ Phab:4049](https://phabricator.haskell.org/4049) is the bump-TcLevel-in-type-sigs patch (Trac [\#14066](https://gitlab.haskell.org//ghc/ghc/issues/14066)), which is based on D3848.
|
|
|
- [\#11715](https://gitlab.haskell.org//ghc/ghc/issues/11715): constraint vs \*
|
|
|
|
|
|
- [\#12088](https://gitlab.haskell.org//ghc/ghc/issues/12088): scc for kind inference (lower priority)
|
|
|
|
|
|
**Little things**
|
|
|
- [\#11715](https://gitlab.haskell.org//ghc/ghc/issues/11715): constraint vs \*
|
|
|
|
|
|
- BUGS
|
|
|
- How to fix [\#11719](https://gitlab.haskell.org//ghc/ghc/issues/11719). We can't ever infer a type variable to have a higher-rank kind (as would seem necessary in this example). But perhaps we should type-check type patterns in a different manner than ordinary types, just like `tcPat` is distinct from `tcExpr`. Then, we could use bidirectional type-checking to get things to work out. This is a pretty significant refactor, though. Is it worth it? Or do we just wait until we have dependent types?
|
|
|
|
|
|
# Fuller list
|
|
|
|
... | ... | |