In the case of ticks, what I gather from a read through of the code that it does is guarantee that all of the tick requests placed between animation frame strobes will all be delivered at the next animation frame strobe. Is that a correct read?
Yes, that is a correct read. But no, I don’t think that your post shows the same can be done with tasks instead of commands. The reason is, as previously mentioned, the existence of andThen for tasks. And your “P.S.” does not address this, because you are not there considering what the real complication with andThen is. The complication is not whether a tick task involved in two andThen chains is run once or twice, the complication is how to deal with the “continuations” in those two chains. Let’s look at this with some example: In the Effects/Cmd world, using ticks would be like this: 1. At some point, a command tick tagger1 reaches the runtime system, where tagger1 : Time -> Msg for Msg being the program’s message type. The runtime system will not do anything at that point, except for registering in some internal state that a tick request was issued, and that the tagger to use for it is tagger1. So essentially, the runtime system (specifically, the effect manager) at that point stores the function tagger1 in some list. 2. At some point after that, but before the next animation frame happens, a command tick tagger2 reaches the runtime system. At that point, the effect manager adds the function tagger2 to said internal list. 3. Some time later, the next animation frame is due. So the runtime system looks at its internal list, sees that there are [tagger1, tagger2], takes the current time stamp t, evaluates msg1 = tagger1 t and msg2 = tagger2 t, and passes msg1 and msg2 to the program’s update function one after the other *but without any intermediate view rendering*. If the update function creates additional effects/commands, the ones created from the calls of update with msg1 and msg2 are batched (so that actually the grouping together of updates will propagate to the future). What about in your hypothetical world in which no Cmd abstraction exists, but instead tick has type Task Never Time? Now instead of just using tick with functions of type Time -> Msg, tick can be used in task chains, like tick |> andThen cont with cont : Time -> Task Never Msg. Let’s look at such a scenario: 1. At some point, a task tick |> andThen cont1 reaches the runtime system, where cont1 : Time -> Task Never Msg. As above, the runtime system shouldn’t do anything at that point, except for registering in its internal state that there is this tick request and what to do when it eventually becomes active. The difference to above is that now instead of storing a function Time -> Msg for later use, the system has to store a function Time -> Task Never Msg. Fine enough. 2. At some point after that, but before the next animation frame happens, a task tick |> andThen cont2 reaches the runtime system, where cont2 : Time -> Task Never Msg. Again, the effect manager should simply add that to the internal list of open tick requests. 3. Some time later, the next animation frame is due. Now what? The runtime system knows that two tick requests are open. So of course it takes the current time stamp t and passes it to the two functions stored in its internal list. But instead of getting some msg1 : Msg and msg2 : Msg as above, it now gets some task1 = cont1 t : Task Never Msg and task2 = cont2 t : Task Never Msg. So *unlike above*, the strategy now cannot be to pass the relevant two messages to the program’s update function while ensuring that no view rendering happens in between (which was the whole point of tick batching in the animation scenario). Because those messages are simply not available right now. What is available are two tasks that when run will eventually return with messages (maybe after some http requests or whatever). So the runtime system can now fire off task1 and task2, but there is no way to tell when they will return, and certainly no assumption can be made that they will return still before the view rendering that is supposed to happen right now because we have an animation frame just due. In consequence, the whole point of tick batching is lost. We don’t get to ensure that groups of update calls get performed “atomically” without intermediate view rendering. What do you think about the above? To me, it means that in the “just tasks” world tick batching as in the “separate tasks and commands” world is not possible (with the same quality). -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
