Fork dunai and let rhine depend on it

[turion]

@ivanperez-keera
There are too many places where rhine development is stalled because of the slow dunai development cycle. I will probably fork dunai, call it dunai-light or dunai-core, throw out everything that isn't the core library (examples, bearriver etc.) and progress in all the issues that currently stall rhine issues. If you want we can later merge.

[ivanperez-keera]

The nature of dunai makes it extensible without forking, for the most part. What features are you missing that need to be in dunai for rhine to depend on it?

Or what needs to change in dunai for rhine to be able to implement something it can't.

[turion]

Glad you asked!

It's impressive how much activity there was in dunai the last 24 hours ;) so a few points of what I'm missing are already there now.

Foremost

• Support for newest GHC (in this case, 8.6), which is necessary to keep dunai, and thus rhine on stackage. That's the most urgent issue right now. Analogous issues will come up again and again if dunai doesn't keep up with stackage nightly.
• Working CI infrastructure (seems resolved for now)
• Consistent naming that can be mirrored in rhine, i.e. Reorg: function naming: no input ivanperez-keera/dunai#99 and similar issues

But also very important for me is that PRs and issues are dealt with timely. If I open a PR I want to hear quickly either 1. merge 2. revise or 3. close (ideally with feedback what to change in case of 2. or 3.). Having them pending without understanding what we are waiting for kills my motivation to contribute any further.

Functionality

There are a lot of smaller and bigger things missing (from my perspective) in dunai (like ivanperez-keera/dunai#112 and ivanperez-keera/dunai#107 and a few other issues and todos in rhine). I can understand if you want to keep all that out and insist that users of dunai should add that code to their own libraries. But I think that more well-written code right in the library serves as good examples and documentation. This would just be a difference in opinions and not a crucial point.

In the long run

• Abstract MSFs as a type class to test different implementations, important for live coding (I want to show live coding with rhine next ICFP). This also requires us to remove the MSF constructor everywhere where it's not necessary.
• Resolve ReaderT commutation, and code duplication between rhines ClSFs and bearriver i.e. Use concurrent-split? #70.
• Possibly add type state in the monad, i.e. indexed monads or so. But that would likely be a separate library.

[turion]

This is stalled by expipiplus1/vector-sized#52

[turion]

The foremost points have all been addressed in the last dunai release (0.5.1). (Thanks to a lot of work by @ivanperez-keera!) Currently, there are no sufficiently important reason to base rhine on a fork. The reasons listed under "in the long run" are not urgent enough right now.

[ggreif]

Is dunai-0.5.1 on Stackage yet?

Ah, I see: commercialhaskell/stackage#4109