So in your vision, it sounds like subscriptions would go away as well? Or would they become an abstraction for some sort of task port interaction?
On Sat, Dec 10, 2016 at 2:34 PM, Mark Hamburg <[email protected]> wrote: > 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. > -- 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.
