On looking at the Task docs again, I see that my "correction" was incorrect. Sorry about that.
On Mon, Jul 11, 2016 at 8:09 AM, Nick H <falling.maso...@gmail.com> wrote: > oops, sorry for the premature send! > > what I was saying is, the argument that gets passed is not an error. But > that's ok, since the argument gets thrown out, you could also just write (\_ > -> (Task.succeed "fallback value")) > > But I agree, using "always" is a very special case. Even though it has > more syntax, I think lambdas are usually just as readable, if not more so. > > "always" also differs in how it gets evaluated. For instance, the > following program crashes. But it would succeed if the always were replaced > by a lambda expression: > > main = > Ok (text "hello") > |> Result.formatError (always (Debug.crash "failure")) > |> Result.withDefault (text "goodbye") > > > On Mon, Jul 11, 2016 at 7:54 AM, Nick H <falling.maso...@gmail.com> wrote: > >> One correction: the argument that gets passed to (\error -> >> (Task.succeed "fallback value")) >> >> On Mon, Jul 11, 2016 at 12:03 AM, Ian Mackenzie < >> ian.e.macken...@gmail.com> wrote: >> >>> So I was playing around in the Elm REPL with various Task functions and >>> stumbled onto the following: >>> > Task.onError (Task.fail "error message") (always Task.succeed 3) >>> <task> : Task.Task a String >>> and I thought huh, that's funny, I was expecting Task.Task a number. >>> Then I realized that I had forgotten some parentheses: >>> > Task.onError (Task.fail "error message") (always (Task.succeed 3)) >>> <task> : Task.Task a number >>> >>> In the first case, always is taking two arguments (instead of one as >>> usual) and simply returning the first argument (throwing away the second), >>> so the code is equivalent to >>> > Task.onError (Task.fail "error message") Task.succeed >>> <task> : Task.Task a String >>> which basically just ends up meaning 'take the error result and promote >>> it to the success result'. >>> >>> In my case the two resulting tasks have different types, but I can >>> imagine a case like >>> > Task.onError (Task.fail "error message") (always Task.succeed >>> "fallback value") >>> <task> : Task.Task a String >>> where I meant to provide a fallback value in the case of an error but >>> end up just using the error message instead. >>> >>> In general I've found how always reads in code to be quite pleasing, >>> but I have to admit this is an argument for using a lambda instead: >>> > Task.onError (Task.fail "error message") (\error -> Task.succeed >>> "fallback value") >>> <task> : Task.Task a number >>> and >>> > Task.onError (Task.fail "error message") (\error -> (Task.succeed >>> "fallback value")) >>> <task> : Task.Task a number >>> are equivalent, very clear, and it's pretty obvious that the latter just >>> has superfluous parentheses. >>> >>> Or maybe this is just a rule to keep in mind, and perhaps something for >>> future Elm linters to check - make sure you only pass one argument to >>> always! >>> >>> -- >>> 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+unsubscr...@googlegroups.com. >>> 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
