foldDynM

[werner291]

Related to: #54

Here's a pull request with the changes I've made thus far that allow foldDyn to be called inside a frame update, added foldDynM which can create new dynamics when events are received.

WORK IN PROGRESS This pull request, at the moment, is mostly meant as a way to comment on the proposed changes more easily, and represents an intent to eventually merge them in. The code is in a somewhat rough state and might need a bit of refactoring and/or reworking. I would strongly advise against merging it right now.

Done so far:

• Refactored the foldDyn into a monad MonadFold
• Implemented foldDynM which can be called in any MonadFRP (might be possible to call inside MonadFold as well with some modifications)
• Used foldDynM in an application (https://github.com/werner291/purechat/blob/f187423b67be44f1fb786ba97cfda9226332187a/src/API/ServerFeed.purs#L214) and confirmed it at least seems to work as intended.

Points to do:

• Assess whether the refactoring of foldDyn into a monad is acceptable so far. Also, notice that foldDyn now pulls the updateOrReadValue to make sure the current event is read, is that a valid thing to do in that situation?
• Look at other (f/h)old* functions and see how those can be made consistent witht he new changes.
• A general review of any changes made.

[zyla]

Hello @werner291 . Thanks for the effort to put it together. Right now I don't have time to dive into this; will try to look at it in a few days.

[werner291]

Ok, sorry about the long silence, there. I spent a couple days thinking about whether this was the best way forward, but some kind of limited monad should indeed be the simplest solution to doing this. The ability to create new state machines was indeed kinda missing.

I briefly looked at whether purescript-behaviors did it better. At first I was surprised they weren't building their stuff in a monad, but they simply delay the creation of the state variables until the event/behavior is subscribed to, which causes state machines to be created once for every subscription.

[srghma]

hi @werner291 , can I help you with this?

[zyla]

Hi @werner291 . Sorry for the very delayed response.

I also ran into the problem of not being able to use subscriptions in a folding function. I think it would be a good idea to have something like foldDynM.

Since you created this pull request, the underlying FRP implementation was esssentially replaced, so a new implementation of your idea will be also needed. However, I think the first step should be specifying the semantics a bit more.

I see Reflex has a similar function, but it's not clear to me what are its semantics wrt subscription management. For example, I'm not sure whether we should keep previous subscriptions when receiving a new value.

For example, suppose we have:

-- assume e :: Event (Dynamic Int)
foldDynM (\d acc -> do
  -- make it require a subscription
  d' <- uniqDyn d
  -- collect them in a list
  pure (d' : acc)
  ) [] e

The question is: after e fires a few times, are we still subscribed to all the previous Dynamics received via e? If no, then we have a list of essentially useless Dynamics. If yes, then what about use cases where we do want to forget about some subcriptions created during processing of previous inputs? We can't, and that would create a memory and subscription leak.