-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reactimate's type requirements seem contrived #16
Comments
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 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:
|
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 :). |
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. |
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:
I'd love to get a pull request... 😁 |
(The commit history and messages should be quite helpful. There's many extensions there.) |
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. |
I had a recent conversation with Henrik Nilsson and he agrees that this is an issue and a better job could be done with |
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. |
reactimate
seems to have some redundancy in its type requirements, more specifically, the two Bool inputs required for the input and output actions.Is there a good reason to not introduce some wrapped functions which simplify this? For instance, I wrote a small module, which I've uploaded in this gist (please forgive my naming), which I find I use rather than
reactimate
directly.(With regards to issue #15,
sReactimate
generalises to all monads with no changes, andyampaMain
should beis fairly straightforward to adjust forMonadIO
actions.)The text was updated successfully, but these errors were encountered: