v2 roadmap - Githubissues

GHC 8.10 is coming up soon-ish, and we've got plenty of old issues, pull-requests and ideas put on the backburner we should get resolved. Some of these are pretty breaking changes, so I'm aiming at making the next patch v2. Here's a to-do list:

For sures

[ ] Finish and merge No More Strategy (https://github.com/polysemy-research/polysemy/pull/239). This amounts to resolving merge conflicts and documentation (but the documentation will be hard.)
[x] Delete deprecated code (https://github.com/polysemy-research/polysemy/pull/242). There's the unresolved question if we should implement runFinalPure :: Sem '[Final Identity] a -> a, change run to that signature, or leave it be.
[x] Implement https://github.com/polysemy-research/polysemy/issues/304.
[ ] Decide what to do about a Mask effect / reworking Resource. We might want to add a Mask effect, and if we do we might want to merge it with Resource. There are some thorny questions for how to go about this. ~~Details upcoming in a issue I'll create today or tomorrow.~~ More thorny than I initially expected. I'll try to get a write-up done for ~~February~~ when I have time and remember to, This includes resolving issues like #268.
[ ] Change runM to also handle Final (i.e. runM :: Sem [Embed m, Final m] a -> m a) and remove runFinal. This'll require changes to documentation, and extra documentation to explain that you can still use runM even though you haven't used the Embed or Final part.
[ ] Documentation. Everything under better-docs should be resolved. An especially important point is to document and write guides about Tactics. This is the part of the library users especially struggle with.

Maybes

[ ] Add #228 and/or #272. These are effects that have non-trivial unresolved questions and thus have been put on the back-burner. Once we decide how to go about these, we may add them to the library (or choose not to).
[ ] Investigate splitting the "functional dependencies" component of the polysemy plugin to a general plugin, that may be used outside of polysemy. In @TheMatten 's words:

I think it would be good idea to investigate possibility of splitting plugin from the library - currently it's strongly tied to internal machinery, even though the concept could potentially work for any type of constraints and could be useful for other libraries. Plus, building some exact model around how it should work would possibly help us make sure that it's actually sound and safe - typechecker plugins are moving on very thin ice by being able to prove whatever bogus constraint they want.

It seems to me that the idea of [the] plugin is basically "functional dependency that get's dropped if it isn't satisfied" - polysemy-plugin does some other things too I think, but if they're domain-specific, they could just stay where they are. The thing is, I can imagine this plugin being helpful for something like eff or mtl-wthout-fundeps, or even something like implicit arguments or field access - I hope that if we split it, we can possibly attract more contributors into it, simply because they find it useful in their own libraries - And we'll be able to reason about it separately. When it comes to safety, It already blow up a few times in type-incorrect code for me - it's not that bad, because I still get other errors and it seems to be fine once I resolve them, but this is something that will need to be investigated and something that's harder to test being limited just to Member machinery.

If 8.10 is released before we complete everything else, the following point will also become relevant:

[ ] Performance. When 8.10 is released, we need to benchmark, study core, and optimize. Questions such as #285 and https://github.com/polysemy-research/polysemy/pull/217#issuecomment-526720142 become relevant.

Questions about the future

[ ] Named effects. We'd like for users to be able to associate effects with identifiers, so that they may target a specific use of an effect without needing to use newtypes (which requires boilerplate and also implies additional invariants, even when only the name matters.). For the moment, this is covered by Tagged, e.g. Tagged "playerCount" (State Int). However, for one, the tag/untag un/packing is kind of tedious, and there's also a coherence issue when multiple modules/packages use the same tag. @TheMatten gives a great example:
Let's say I have:
```
module A where
foo :: Member (Tagged "log" (Output String)) r => _
```

module B where bar :: Member (Tagged "log" (Output String)) r => _

> In some other part of code, I use them together, but forget to point them into corresponding "foo log" and "bar log", having `Tagged "log" _` in scope again, because I find it to be a useful pattern for some terrible reason:
```haskell
do
  ..
  foo _
  bar _
  ..

It happily typechecks - with local model, it would ask "which one is log?", with global it would ask "where is my A.log and B.log?"

The only real solution to this -- if we want to go down that route -- is to implement a GHC plugin for type identifiers. If we do, we can also support neat syntax for these, such as:

foo :: Members { playerCount :: State Int } r => ...

and desugar it into whatever internal representation we choose to have. The choice of internal representation is a thorny one. Preferably, named effects should be opt-in and invisible when they're not used, and the way we represent them should ideally allow for that. We don't want the representation of the effect row to be changed to something too confusing just to support named effects. This might not be possible for solutions that solve the coherence problem. If we can't solve this in a clean way, then this is a big argument for sticking with Tagged, because Tagged is expressed in terms of the already existing representation of the effect row, and is explicitly opt-in.

We won't implement a solution for v2, but we should decide on what direction we should go in.

polysemy-research / polysemy

v2 roadmap #307

For sures

Maybes

Questions about the future