Dunai/Bearriver - FRP - New version and hacktoberfest


#1

Dear all,

I am very excited to announce a new release of dunai, the reactive framework based on Monadic Stream Functions. This implementation includes parallel combinators “for free” via the list monad.

http://hackage.haskell.org/package/dunai

Coupled with Dunai we are releasing a new version of Bearriver, an FRP Yampa replacement that sits on top of Dunai. Bearriver does not compete with Yampa, it is simply meant as a way to showcase how complete FRP implementations can be created using Dunai with very little code. Bearriver has been used to run whole (real) games.

As a way to get more people involved, we are going to quickly select some issues to work on during October for hacktoberfest. If you are interested, please come over and comment on what you’d like to work on or propose a new idea. Proposals do not need to include new features: demos, tutorials, documentation and code cleaning are perfect as well.

https://github.com/ivanperez-keera/dunai/issues/145


#2

Do you mean that bearriver is not ready yet to replace Yampa, or do you mean that it will never replace Yampa? I would think that an implementation on top of dunai would be smaller and easier to maintain than the original Yampa.


#3

Indeed, an implementation based on dunai would be better in many ways.

Yampa has been there for a long time, and we want to do this right. I don’t want people to see their code break, but improve over time.

So far, we’ve ported the core of Yampa, and work under the assumption that everything is expressible in terms of Yampa core. If one day we can assert that bearriver has 100% the same API as Yampa, is not slower for any significant application, does not consume substantially more memory, does not make error messages harder to understand, etc. then it could make sense to make bearriver the new Yampa.

I’d probably opt for “killing” bearriver and keeping Yampa alive, which has been there for much longer. There’s some fundamental differences, like the fact that, in principle, bearriver signals do not exist at time 0 and Yampa’s do, and we’d have to have a compelling story for that. And I’d speak with Henrik Nilsson and Antony Courtney before doing something this big.

There are games that compile against Yampa or bearriver based on a flag in the cabal file, so it’s already pretty functional as it is. However, there is no urgency in this IMO. I find that implementing the core of other stream languages and FRP flavours on top of dunai should have higher priority.


#4

If you opt for “killing” bearriver and keeping Yampa alive, then it means having signals at time 0 (which is Yampa) is better than not having it (which is Bearriver)?


#5

That is a really hard question to answer. We’ve long debated that, and have not settled on an answer yet.

There are at least two moments when this question arises in FRP: during switching and at the beginning of the simulation. During switching, the key constraint I can think of is that the signal must be defined at all points in time (including at the time of switching), which is possible both in Yampa and Bearriver. At the beginning of the simulation, bearriver signals are only defined at time zero if you allow for time deltas to be zero and impose via some external mechanism that it be positive from that point on. However, if you (can) make a mistake and a time delta is zero during the simulation, that would allow a signal to be defined twice for the same point in time, violating FRP’s conceptual referential transparency. Alternatively, if time deltas are always (strictly) positive, then a bearriver SF does not produce a signal at time zero. While this may seem absurd, it could help deal with some issues in GUI implementation (model and view are mutually dependent and you could create a loop where the view depends on the value of the model at time zero, the model depends on the value on the view at time zero, and neither are well defined).

It feels more of a research question than just an implementation question. So, I’d be happy to know opinions and reasons to opt for one or the other.