And I do get the mathematically wrong answer on foldl when using > mathematically non-associative operations (like subtraction). That's > provided we agree on the definition of which side of the list is the "left" > side.
Well, still not quite for me. I’m sure we both agree what the “left” side of the list is. And still I don’t think there is an argument to make that hence Elm’ foldl‘s answer is mathematically wrong. The fact that we agree what the left side of the list is does not mean that foldl (-) 0 [1,2,3] needs to evaluate to ((0 - 1) - 2) -3. It can evaluate to 3 - (2 - (1 - 0)) without us disagreeing what is “left”. In other words, “leftiness” is not at issue here. Both ((0 - 1) - 2) -3 and 3 - (2 - (1 - 0)) do work “from the left”. They combine elements in the order in which they appear in the list *from left to right*. One could argue that the real thing at issue here is not what “left” means, but what “folding” means. You take it to mean to literally replace :: by (-) and you are only willing to argue about how the result is bracketed. But one can take “folding” to simply mean that stuff gets accumulated via an operator, and “left folding” then means that more-left-sitting elements get accumulated earlier. And Elm’s foldl is perfectly mathematically correct according to this meaning. Of course, that’s back to a point I made already the other day. There’s nothing “mathematically wrong” about Elm’s foldl unless one postulates “mathematically correct” to mean “ foldl needs to be the specific operation it is in Haskell etc.” But that’s not a mathematical argument. -- 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.
