Moving this thread over to Elm discuss (where it probably belonged all the time — I think these things get started on elm-dev because it feels like a better place to get "directional" attention).
The more I think about it, the harder time I have justifying commands. I'm interested in what others in the community — obviously particularly Evan — have to say. A command represents a way to request that some action occur in the "outside world" possibly with a responds back to the Elm world. Doesn't a task also represent that? We speak of an update function returning some commands to perform — interestingly represented as a single command — but would not a list of tasks be just as clear a notion? Could we not say "update returns a new value for the model and a list of tasks to perform that may result in new messages to feed into update logic"? The point to this is that I'm not sure in what way commands make things simpler or more approachable. Commands are easier to route for nested uses, in part because of the single command result and in part because of standard support in the default environment. But surely a list isn't that hard to deal with and we could have a standard function: TaskList.map fn taskList = List.map (Task.map fn) taskList assuming that we've defined TaskList msg to be something like List (Task Never msg). Commands tie into the effects manager system but that's at this point still an undocumented portion of Elm and I don't see why effects managers could not also work with tasks. In fact, having effects managers work with tasks would increase the ability for one effects manager to leverage another. So, my naive conclusion is that commands are inferior to and subsumed by tasks in every way. In particular, commands can't be composed the way tasks can. What's more, commands don't seem dramatically more clear or easy to work with beyond a bit of extra support in the standard libraries that could just as easily be provided for tasks. What am I missing about commands? What problems with tasks am I missing? How does one explain to a new Elm programmer — I've been dealing with several lately — why there are two seemingly very similar concepts in the system and how one should know which one to use when? Imagine a future version of Elm in which commands are replaced by tasks. Command ports are replaced by task ports that leverage JavaScript promises to provide for deferred/asynchronous JavaScript execution. My feeling this morning is that the result in a simpler and more powerful language/system. What would we be lost by going in this direction? What might be gained? Mark On Fri, Dec 9, 2016 at 12:09 PM, Mark Hamburg <[email protected]> wrote: > You beat me to it on posting this suggestion. That said, I might define > Cmd msg as an alias for either Task msg msg or Task Never msg — I'm not > sure which without writing more code. > > Mark > > On Fri, Dec 9, 2016 at 11:37 AM Frank Bonetti <[email protected]> > wrote: > >> > If we would have conversions in both ways (Task <-> Cmd) then why would >> we have 2 things at all? Wouldn't it be better to just use more powerful >> one? >> >> I think this is a really interesting thing to bring up. Please correct me >> if I'm wrong, but I conceptually view Tasks as computation builders and >> Cmds as Task runners. The only purpose of a Cmd is to execute something >> externally/asynchronously and then return a Msg. Why do we need a separate >> data type to do this? Imagine if we just used tasks instead: >> >> *Html.program* >> >> program : >> { init : (model, List (Task msg msg)) >> , update : msg -> model -> (model, List (Task msg msg)) >> , subscriptions : model -> Sub msg, view : model -> Html msg >> } -> Program Never model msg >> >> >> If we removed Cmds, we wouldn't need Task.perform or Task.attempt at all. >> We could instead use map and mapError to produce tasks of type Task msg >> msg. >> >> myTask : Task Msg Msg >> myTask = >> Http.getString "https://example.com/books/war-and-peace"; >> |> Http.toTask >> |> Task.map HandleSuccess >> |> Task.mapError HandleFailure >> >> >> I don't know if this is a better approach, but it's worth asking if Cmds >> are necessary when we are already have Tasks. >> >> >> >> >> On Thursday, December 8, 2016 at 10:44:24 AM UTC-6, Fedor Nezhivoi wrote: >> >> If we would have conversions in both ways (Task <-> Cmd) then why would >> we have 2 things at all? Wouldn't it be better to just use more powerful >> one? >> >> Sorry if the question is stupid. >> >> On Thu, 8 Dec 2016 at 18:28, Max Goldstein <[email protected]> wrote: >> >> I doubt it's possible, but if it is, that would be a great way to assure >> that one can always fall back to tasks if necessary. >> >> >> >> >> >> -- >> >> >> You received this message because you are subscribed to the Google Groups >> "elm-dev" group. >> >> >> >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> >> >> >> >> To view this discussion on the web visit https://groups.google.com/d/ >> msgid/elm-dev/32c80252-edec-4f20-a357-80a23089cf52%40googlegroups.com. >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> Best regards, >> Fedor Nezhivoi >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> You received this message because you are subscribed to the Google Groups >> "elm-dev" group. >> >> >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> >> >> To view this discussion on the web visit https://groups.google.com/d/ >> msgid/elm-dev/bc5b16d5-868b-4c45-b8a9-2672f4ee2158%40googlegroups.com >> <https://groups.google.com/d/msgid/elm-dev/bc5b16d5-868b-4c45-b8a9-2672f4ee2158%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> 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.
