{"action":"created","issue":{"url":"https://api.github.com/repos/HeinrichApfelmus/reactive-banana/issues/141","repository_url":"https://api.github.com/repos/HeinrichApfelmus/reactive-banana","labels_url":"https://api.github.com/repos/HeinrichApfelmus/reactive-banana/issues/141/labels{/name}","comments_url":"https://api.github.com/repos/HeinrichApfelmus/reactive-banana/issues/141/comments","events_url":"https://api.github.com/repos/HeinrichApfelmus/reactive-banana/issues/141/events","html_url":"https://github.com/HeinrichApfelmus/reactive-banana/issues/141","id":182636811,"number":141,"title":"Stateful reactimate and Accessing behavior's new value","user":{"login":"lspitzner","id":7702390,"avatar_url":"https://avatars.githubusercontent.com/u/7702390?v=3","gravatar_id":"","url":"https://api.github.com/users/lspitzner","html_url":"https://github.com/lspitzner","followers_url":"https://api.github.com/users/lspitzner/followers","following_url":"https://api.github.com/users/lspitzner/following{/other_user}","gists_url":"https://api.github.com/users/lspitzner/gists{/gist_id}","starred_url":"https://api.github.com/users/lspitzner/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lspitzner/subscriptions","organizations_url":"https://api.github.com/users/lspitzner/orgs","repos_url":"https://api.github.com/users/lspitzner/repos","events_url":"https://api.github.com/users/lspitzner/events{/privacy}","received_events_url":"https://api.github.com/users/lspitzner/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/HeinrichApfelmus/reactive-banana/labels/question%20&%20answer","name":"question & answer","color":"c7def8"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-10-12T21:18:58Z","updated_at":"2016-10-14T13:37:40Z","closed_at":null,"body":"While making an attempt to provide a bananacific interface for `brick` I ran into two issues/use-cases/questions that I'd like your feedback on. I will link to the relevant bits in the current implementation below; if you are interested [this is the full draft of the interface implementation](https://github.com/jtdaugherty/brick/pull/85/commits/257ceb5578610055a84ebca36495c7864da5ed0b)(includes a rather simple example application.)\r\n\r\n1) Is there a \"proper\" way to handle the following scenario: I have some stateful action `::s -> IO s`, some initial state `::s` and some `::Event ()`. I'd like to execute the action whenever the event fires, updating the \"current\" state.\r\n\r\nMy current solution involves an `IORef` to save the state, which I find rather ugly.\r\n[Relevant lines in the brick interface](https://github.com/lspitzner/brick/blob/257ceb5578610055a84ebca36495c7864da5ed0b/src/Brick/MainBanana.hs#L130-L136)\r\n\r\nSome thoughts around this:\r\n\r\n- I assume the proper way involves a `Behavior` capturing the state\r\n- Not using any IORef, judging simply by types, I can only see two ways to get `s` from `IO s` into `Behavior s`: \r\n    1. `execute` + `switchB`\r\n    2. `newEvent` + `stepper` with `action >>= behaviourEventH`.\r\n- The first approach does not work (and probably is not supposed to) for the reasons already listed on the `execute` docs (and yes, I tried anyways..).\r\n- The second involves a separate event, leading to worse performance (probably insignificant) but more importantly making the executing non-atomic. If I understand banana semantics correctly, it would be entirely possible that two threads fire the first event nearly simultaneously in a way that results in a destructive update of the state.\r\n\r\n#122 is somewhat related.\r\n\r\n\r\n2) When I have an `e :: Event a`, `f :: a -> b -> b`, `g :: a -> c -> c`, `b :: Behavior b`, `c::Behavior c`, where the behaviors are some `accumB` over `e` via `f`/`g`. Is there any way to `reactimate` some action depending on `e` and the _updated_ values of `b` and `c` in the same instant, without calculating `f` and `g` twice? \r\n\r\n[My current solution in the brick interface](https://github.com/lspitzner/brick/blob/257ceb5578610055a84ebca36495c7864da5ed0b/src/Brick/MainBanana.hs#L112) to this is to drop the \"in the same instant\" constraint and have some event e' that happens right after e', allowing to access the updated behaviors when e' occurs. This solution works fine in this case, yet I am not completely happy - for other cases I foresee the possibility of running into some equivalent of destructive updates from above (e.g. by some requirement to reactimate each `b`/`c` combo exactly once - which again would clash in some multiple-threads-firing-`e` case).\r\n\r\n--\r\n\r\nI perhaps should add that the brick-interface as designed in the links seems to work fine already (and performance for this application of banana is noncritical anyways); my questions are more about scaling with more complex use-cases in mind.\r\n"},"comment":{"url":"https://api.github.com/repos/HeinrichApfelmus/reactive-banana/issues/comments/253800861","html_url":"https://github.com/HeinrichApfelmus/reactive-banana/issues/141#issuecomment-253800861","issue_url":"https://api.github.com/repos/HeinrichApfelmus/reactive-banana/issues/141","id":253800861,"user":{"login":"lspitzner","id":7702390,"avatar_url":"https://avatars.githubusercontent.com/u/7702390?v=3","gravatar_id":"","url":"https://api.github.com/users/lspitzner","html_url":"https://github.com/lspitzner","followers_url":"https://api.github.com/users/lspitzner/followers","following_url":"https://api.github.com/users/lspitzner/following{/other_user}","gists_url":"https://api.github.com/users/lspitzner/gists{/gist_id}","starred_url":"https://api.github.com/users/lspitzner/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lspitzner/subscriptions","organizations_url":"https://api.github.com/users/lspitzner/orgs","repos_url":"https://api.github.com/users/lspitzner/repos","events_url":"https://api.github.com/users/lspitzner/events{/privacy}","received_events_url":"https://api.github.com/users/lspitzner/received_events","type":"User","site_admin":false},"created_at":"2016-10-14T13:37:40Z","updated_at":"2016-10-14T13:37:40Z","body":"Regarding 1): But if I have multiple reactimates, the current implementation has no problem to execute them in some (arbitrary?) order, either.. and if the reactimated actions fire events that affect behaviors, the outcome _already_ is arbitrary. That is: I cannot think of an example (with two or more behaviors connected in some way that cause ordering-problems) where your proposed solution would be more deterministic than the arbitrarily-ordered same-instant execution which I wondered about."}}
{"actor":{"display_login":"lspitzner"}}