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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 [email protected]. >>> 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.
