bearriver: base bearriver and Rhine's SyncSF on the same footing

[turion]

It seems like there is a lot of code duplication between bearriver and Rhine's SyncSFs. The basic idea is the same in both cases: Add an outermost ReaderT TimeDiff layer to MSFs which represents the time difference since the last tick.

I'm proposing to find a common basis to both in order to avoid code duplication.

Duplicated code

Already present

• Basic type definitions
• Integrals, derivatives

Where we could merge code from one to the other

• rhine -> bearriver: Exception handling
• bearriver -> rhine: Random number generation

Where we could avoid duplication in the future

• Resolution of bearriver: RandT and other transformers don't work directly #65
• Monad transformer wrapping and running. Note that it's not possible to directly apply the wrapping and running functions to SFs. (See this issue.)

Proposal

1. Take https://github.com/turion/rhine/blob/master/rhine/src/FRP/Rhine/SyncSF.hs and some parts from bearriver and make a new package out of it. (Could be hosted in the dunai repo.)
2. Since time deltas are handled slightly differently in Rhine and bearriver, create a type class TimeDiff to capture the essence that is needed.
3. Generalise the implementations of integral etc. to work both for Rhine and bearriver.
4. Port exception handling and random numbers there.
5. Make bearriver into a thin wrapper that does nothing else than just recreating the Yampa API.

Advantages

• Avoid code duplication
• Join efforts

Disadvantages

• Yet another FRP framework
• Might lose flexibility in some places because we have to find the common denominator?
  • One such possibility: Rhine's SyncSFs aren't just MSF (ReaderT TimeDiff m) a b, but actually MSF (ReaderT TimeInfo m) a b, where TimeInfo holds the time delta since the last tick, and the beginning of the program, and the absolute time (e.g. UTCTime).

[turion]

Question: How would we call the fundamental building block, i.e. an MSF (ReaderT TimeDiff m) a b? Simply SF m a b or SyncSF m a b or something different?

[turion]

One way to rephrase this is the following:

Bearriver is two things:

1. It's an honest synchronous FRP library with effects.
2. It's a compatibility layer to Yampa.

I think these are two different aspects, and I want to separate them more clearly. I want to use 1. for rhine, without having 2.

[turion]

One possible name is BehaviourF, following Rhine.

[turion]

@ivanperez-keera, such a package might be the right place to put your time transformation ideas, self-clocked MSFs, and your other ideas from "Back to the Future".

[turion]

I think it's a better idea not to create a separate package for this, but just to make this a module in dunai.

[ivanperez-keera]

While this might be an improvement in same ways, it also adds yet another level of indirection to understand, explain or work on Bearriver.

Once I become more familiar with rhine, maybe this will bug me enough or I'll decide to factorize stuff.

In the meantime, it doesn't. So, if there's some duplication between rhine and bearriver, there will have to be.

[turion]

@ivanperez-keera Is #174 enough to revisit this issue here?

[ivanperez-keera]

Not as such, or not based on what I understand currently.

I've been giving talks about Dunai, Bearriver and Rhine. I would not find it easier to describe if we add additional layers, and I think, in the long run, it's going to be much better for the project as a whole that beginners find a really, really low entry barrier to understand the concepts described.

Additionally, I'm currently trying to reduce the burden of maintaining all of this work, and this would not make it immediately easier for me. My current focus atm. is on cleaning all of this and documenting it well. Right now, I cannot answer off the top of my head what is in dunai and where it is defined, and that really, really bugs me because I simply cannot understand the impact that other changes will have, or other improvements we could bring to all of these libraries.

[turion]

Makes sense. In that case, I'd recommend duplicating the code from Rhine's monad handling to Bearriver. Would you like a PR doing that?