I don't think this needs to eliminate subscriptions. Subscriptions do represent a different sort of concept. The problem with tasks and commands is that they represent concepts that greatly overlap. I used to describe this to coworkers who questioned it as being two concepts needed to cover what was really one and a quarter concepts worth of material. But as this thread got me thinking about it — spurred on also by my separate frustration when asked by coworkers about how to do something that would require chaining commands because the functionality hadn't been exposed as tasks — I realized that it doesn't take much to expand tasks to cover what commands now cover thereby eliminating the why are the two things to cover seemingly the same territory question.
Mark (*) I will say that I worry about the efficiency of subscriptions since my understanding is that they are updated after every update cycle, but that's a separate matter about how exactly subscriptions work and not about whether they could be subsumed by something else. On Sat, Dec 10, 2016 at 3:11 PM, Nick H <[email protected]> wrote: > 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. > -- 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.
