Does Elm guarantee ordering between Task.succeed callbacks & external async. inputs?

[Desmond D'Souza]

Say I have an asynchronously triggered action "a" that causes 2 immediate callback actions "b" and "c" via Task.succeed, like this:

update : String -> Int -> (Int, Effects String)

update act m =

  case act of

    "a" -> (m + 1, Effects.batch [ "b" |> Task.succeed |> Effects.task,

                                   "c" |> Task.succeed |> Effects.task ])

    -- "b", "c" -> handled here
    -- others_cases -> handle async ones from GUI or server

When the first "a" is processed, does Elm guarantee the corresponding "b" and "c" callbacks will be processed before any async other_cases like asynchronous GUI or server events that arrived while the first "a" was still being processed?

If so, is this guarantee made by the language? Current implementation? Both?

(If not, I will need to re-structure my design).

Thanks!

[Desmond D'Souza]

Btw, my guess would be "No such guarantee" -- once you are in Task-land everything is async. But since Task.succeed is documented as "a task that succeeds immediately", I was wondering if that provided some additional guarantee.

[Max Goldstein]

I wouldn't think there is a guarantee.

My guess is that Task.succeed includes setTimeout(someFunction, 0) somewhere, which means that the JS runtime will execute the function as soon as it can, but not necessarily before other timeouts similarly queued have run.

[Peter Damoc]

The way I understand Task code is like a set of instructions you might give to a butler. You never do things yourself, all that is done for you by the runtime. 

And so... if you need things to happen in a certain order, you should connect them in the order you want them to happen. 

For me, time only exists in the runtime. 

--
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 elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Peter Damoc]

On Sun, Oct 4, 2015 at 6:30 PM, Desmond D'Souza <des...@dsouzaville.com> wrote:

Btw, my guess would be "No such guarantee" -- once you are in Task-land everything is async. But since Task.succeed is documented as "a task that succeeds immediately", I was wondering if that provided some additional guarantee.

One of the key understandings for me regarding the Task code was when I understood that the tasks connected with `andThen` do not produce a "list of tasks" but they produce one single task. The elements of a sequence of tasks are not like beans on a wire but like a matroska doll. 

So, when I see "a task that succeeds immediately" I don't read that like: that it will be so fast that the "next" task will most definitely be executed "after" it.  I read it like.... probably the runtime has enough information to just replace the call for execution with the value when the time comes.  

In a cooking metaphor, it would be the equivalent of providing a recipe where the person needs to find some ingredients BUT also providing one of the ingredients together with the recipe. The person doing the cooking still needs to "get" the ingredient but since it received the ingredient together with the recipe, it can "skip" certain checks. 

On Sunday, October 4, 2015 at 1:12:21 AM UTC-5, Desmond D'Souza wrote:

Say I have an asynchronously triggered action "a" that causes 2 immediate callback actions "b" and "c" via Task.succeed, like this:

update : String -> Int -> (Int, Effects String)

update act m =

  case act of

    "a" -> (m + 1, Effects.batch [ "b" |> Task.succeed |> Effects.task,

                                   "c" |> Task.succeed |> Effects.task ])

    -- "b", "c" -> handled here
    -- others_cases -> handle async ones from GUI or server

When the first "a" is processed, does Elm guarantee the corresponding "b" and "c" callbacks will be processed before any async other_cases like asynchronous GUI or server events that arrived while the first "a" was still being processed?

If so, is this guarantee made by the language? Current implementation? Both?

(If not, I will need to re-structure my design).

Thanks!

--

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 elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.