> "independently, concurrently, in the order they're provided"
This is a contradiction. Even if the runtime started the tasks at the same time, the works they do can complete in any order. Either your code (Elm or otherwise) should work with any ordering, or you should sequence things in Elm tasks. I'm well aware that the tasks can *complete* in an order. I was just wondering why the commands are *started *in reverse order. > If the runtime is iterating through the list backwards, that's an implementation detail. Is it just an implementation detail? If the documentation clearly stated that you should not expect the commands to be started in any particular order, sure, this would be an implementation detail, but as it stands this behavior is "undefined". It's kind of like how Set orders the elements it's given. Set.fromList [4,2,5,3,1] |> Set.toList == [1,2,3,4,5] This happens because Set is implemented as a Dict, and Dict is implemented as a binary tree. You might call this an implementation detail, but I wouldn't because it affects what the function returns. A true implementation detail doesn't affect the output. On Friday, May 12, 2017 at 11:46:53 AM UTC-5, Max Goldstein wrote: > > "independently, concurrently, in the order they're provided" > > This is a contradiction. Even if the runtime started the tasks at the same > time, the works they do can complete in any order. Either your code (Elm or > otherwise) should work with any ordering, or you should sequence things in > Elm tasks. > > If the runtime is iterating through the list backwards, that's an > implementation detail. > > -- 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.
