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?
If so, in a task based world, what it would call for is a function of the form: tick : Task Never Time Remember that we can pass a task off to the runtime system and it will run each time we pass it off, so while this declaration defines a statically created task, it can be used repeatedly to get different ticks. (If I am wrong about this aspect of how tasks work, that would change some of this though it could be adapted to the change and it would be an interesting addition to the strength of tasks as essentially being promises for work to be done rather than being a way to represent work to be done.) Now, how, would we implement batching? Let's assume that as a replacement for commands, we gain the ability to create task ports: port tick : Task Never Time Or if we have to make them all be functions for consistency: port tick : () -> Task Never Time Remember though that we could then just call this function once to get a reusable task. What happens when we execute a port task? It isn't the task that resolves but rather the execution of the task so initiating execution of a task creates a task execution in the runtime. In the case of port tasks, the proposal that's been floated — first by others but I like it — is that the underlying JavaScript code would be invoked and expected to return a promise which when resolved would resolve the task execution and feed into whatever follows next. But now we see that tick batching is just a matter of caching the outstanding tick promise and clearing this promise when the requested animation frame arrives. The net execution logic is essentially the same, but if anything it's simpler than what was needed for Elm 0.16. In terms of 0.17+ effects managers, this is basically just a lifting of the JavaScript code into Elm. The command values that effects managers construct could be wrapped inside of tasks and those values would be delivered to the effects manager for further processing when the task was executed. So, no, tasks as currently implemented aren't sufficient to replace commands — if only because we have ports that can generate commands and we don't have ports that can generate tasks — but my point is that the task system could be extended slightly and without additional intellectual complexity to cover what commands cover and Elm could thereby drop from two concepts to one. Mark P.S. One area of complexity: Since tasks are just data, if you take the same task value and then chain two things off of it via either Task.map or Task.andThen and then bring them back together for execution, does the underlying task get run once or twice? I can define runtime models that make sense both ways. This doesn't come up with commands because they don't allow one to build more complex arrangements and it only matters from a performance standpoint if the task operation is functional. My inclination would be to say that you get different executions of the task for each time it is reached in a traversal of the graph and if you don't want that you should structure your graph so it can only be reached via one path. On Sat, Dec 10, 2016 at 11:52 AM, Janis Voigtländer < [email protected]> wrote: > Those are Elm 0.16 effects are something totally different. There is no >> reason why tick tasks couldn't be batched in their execution. > > I disagree. I said I’m not authoritative, and meant that I can’t speak for > *all* the possible reasons that Task and Cmd cannot be unified into one > concept. But what I can say is: > > - Elm 0.16 effects are not something totally different. In fact, the > Effects type from that package is the direct predecessor of the Cmd > type, and the implementation of the “tick batching trick” was the first > nontrivial effect manager (though that concept didn’t have a name back > then). If you can substantiate the claim that 0.16’s Effects and > 0.17’s Cmd type constructors are totally different, I would be > interested to hear the argument. > - I was the person who implemented the “tick batching trick” back > then. I can tell from that experience that to make it work, an abstraction > was needed (but preexisting, not “invented” by me) that absolutely mustn’t > support an andThen operation like Task does. So on that specific > count, I can with a bit of authority contradict your assertion that there > is no reason why tick tasks couldn’t be batched (with the same quality as > Effects/Cmds can). > > > > -- > 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. > -- 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.
