Re: [elm-discuss] Proposed addition for Task package

2016-11-23 Thread Magnus Rundberget
I'm definately with Wouter on this one. Using tasks to do something that isn't a side-effect sounds much more like a code smell than using plain old function calls and function return values to compose your logic (when that is possible, which I would imagine would be true most of the time, if

Re: [elm-discuss] Proposed addition for Task package

2016-11-22 Thread Charlie Koster
> > The log then shows that between the DoStuff message and the DoMore > message, a Tick message comes in. > Well, that's troubling and undermines my assumption. That's for looking into this. For those skimming through this post, *race conditions are possible when doing something like

Re: [elm-discuss] Proposed addition for Task package

2016-11-22 Thread Wouter In t Velt
For those interested: here is the example I refered to: import Html exposing (..) import Html.Events exposing (onClick) import Time exposing (Time, second) import Task main = Html.program { init = init , view = view , update = update , subscriptions = subscriptions } --

Re: [elm-discuss] Proposed addition for Task package

2016-11-22 Thread Wouter In t Velt
Op dinsdag 22 november 2016 14:49:47 UTC+1 schreef Charlie Koster: > > My assumption is a race condition here wouldn't be possible since calling > `sendMsg MyMsg` is a synchronous action > I have tried it out in elm-lang.org/try, which suggests that it is asynchronous, in a simple setup -

Re: [elm-discuss] Proposed addition for Task package

2016-11-22 Thread Charlie Koster
> but I have seen terrible bugs being introduced by improper use, caused by > Cmd messages being created based on model state A, and because of race > conditions (e.g. fetch results coming in in the meantime) > My assumption is a race condition here wouldn't be possible since calling

Re: [elm-discuss] Proposed addition for Task package

2016-11-22 Thread Wouter In t Velt
Op dinsdag 22 november 2016 13:47:55 UTC+1 schreef Charlie Koster: > > I respectfully disagree. Depending on the application, this either may not > be possible or would be a terrible code smell. I honestly think the above > suggestion would be worse than chaining another Cmd msg. Sending another

Re: [elm-discuss] Proposed addition for Task package

2016-11-22 Thread Charlie Koster
> > One reason is what Evan says at > https://github.com/elm-lang/core/blob/master/CONTRIBUTING.md#adding-new-functions: > > new functions are not so quickly expected to go into core, instead to be > accumulated in *-extra packages first. > I didn't realize that was the case. Thanks for the

Re: [elm-discuss] Proposed addition for Task package

2016-11-22 Thread Wouter In t Velt
My 2c: I kind of like it that there is NOT such a function in the core. Because it *prevents me from grabbing it when I really shouldn't*. Especially if the `Cmd` has no side effects, it is better to do a recursive call to the `update` function, or better yet: call the function that your

Re: [elm-discuss] Proposed addition for Task package

2016-11-21 Thread Nick H
 On Mon, Nov 21, 2016 at 7:04 PM, Charlie Koster wrote: > I'm a fan of the changes to Task.perform in Elm 0.18. However, I'm still > finding that I'm writing a lot of boilerplate in some situations. For > example, there are several instances when I want to send a msg

[elm-discuss] Proposed addition for Task package

2016-11-21 Thread Charlie Koster
I'm a fan of the changes to Task.perform in Elm 0.18. However, I'm still finding that I'm writing a lot of boilerplate in some situations. For example, there are several instances when I want to send a msg which has no payload. Task.perform (\_ -> GoToLoginPage) (Task.succeed Nothing) I do