reactimate's type requirements seem contrived about yampa HOT 8 CLOSED

I agree that the signature is overly complex. I tend to think of reactimate as:

reactimate :: (IO a, IO (DTime, a)) -> (b -> IO Bool) -> SF a b -> IO ()

I also define my own alwaysReactimate, which is similar to yours.

I'll discuss the change with Henrik Nilsson and get back to you.

Regarding the way that you are structuring your code: we are experimenting with two new additions; you might want to keep an eye open for these two babies:

• One is signals and sinks (https://github.com/ivanperez-keera/Yampa/blob/signalsink/src/FRP/Yampa/Signal.hs). It can be separated completely from Yampa, there is no need to make them first-class citizens in the FRP dimension.

  They can be made applicative functors, combined and mixed, etc. That gives a nice, modular way of structuring inputs and outputs. They also pave the way to communicate different reactive and FRP libraries, such as https://github.com/keera-studios/keera-hails (Reactive Values would become sources and/or sinks in this vocabulary).

  For instance, I have an SDL clock signal defined in a separate library, and I often pair it with a game input source to obtain a game input signal.

• The second addition are local clocks. We (Manuel Barenz and me) have been exploring adding clocks to SFs. It is being kept in a separate branch for now. We have experimented with downsampling and upsampling, busy clocks, constant FPS clocks, etc. They are run independently: a top-level SF with a clock ticking every 10ms might contain another SF with a clock at 1ms that actually runs at that speed. A dependently-typed language would be best to express this, but we've done it in haskell as an extension of Yampa for now.

from yampa.

Great; I think either modification would be an improvement.

Thanks for the heads-up. A modular way of dealing with inputs and outputs makes a lot of sense. The expression of signal functions in Yampa seems clean, but (at least from my baby Haskeller perspective) the input and output parts feel clumsy, since I find myself passing around custom built data types an awful lot, which of course need to be built... I think monadic reactimate is the other component in this tidying.

Hails looks cool. Will take a closer look at that soon :).

from yampa.

Sorry. This hasn't moved forward in quite a while. It's totally my fault. I don't want to pollute Yampa with my own extensions too much, in part just to make sure people see Yampa as something stable. But the price we are paying is severe stagnation :(

Maybe we can put all these things in a yampa-extra library for now and merge what we like in the future? (I'll also discuss it with Henrik Nilsson next week.)

Can anyone suggest a better name for the library? Yampa extra does not convey much.

from yampa.

These changes have now been introduced into the branch we use at Keera Studios for our games, develop-games.

The only thing left is a simulation/reactimation function that uses that. Probably something along the following lines:

reactimateS :: (Signal sa a, Sink sb b) => sa -> sb -> SF a b -> IO ()

I'd love to get a pull request... 😁

from yampa.

(The commit history and messages should be quite helpful. There's many extensions there.)

from yampa.

Sorry, I was unaware of the previous updates (github isn't wonderful at flagging them if you miss the email).

It's been a while since I did anything with this, but I might dive in and take a look to see if I can cook something up. At first glance this looks reasonable.

Looking back at your message from a few months back, I think maintaining a solid core is a sensible idea.

from yampa.

I had a recent conversation with Henrik Nilsson and he agrees that this is an issue and a better job could be done with reactimate.

from yampa.

This issue is currently stagnated. It seems that it may take too long, and may need to be explored more as a research question. there's relations with Dunai and the work in the paper FRP, Refactored.

Reactimate has been generalized for all monads now. Let's continue as is. This can be explored as a research question and, perhaps in the future, improved accordingly. Keeping this in an open state without a clear goal is not going to help us progress.

Closing for now, re-open or file a new issue if you have a concrete proposal.

from yampa.