I would like to point out that: I’m sure neither of us is too stupid to know what the other means. :-)
And I don’t think there is no basis to discuss these aspects. In fact, here is a possible explanation of why this all seems so fuzzy: One could distinguish between “from left to right in terms of the input” and “from left to right in the output”. Then: - ((0 - 1) - 2) - 3 processes elements from left to right in terms of the input and happens to produce an expression that is nested from left to right in the output - 3 - (2 - (1 - 0)) processes elements from left to right in terms of the input and happens to produce an expression that is nested from right to left in the output The distinction you make between “head to tail” and “left to right” (as if you would be fine with the current Elm behavior of foldl aka foldLeftToRight if it were simply called foldHeadToTail instead) is not one I can relate to. 2016-12-15 20:31 GMT+01:00 Kasey Speakman <[email protected]>: > foldl doesn't say it folds head to tail (which would be accurate). It says > it folds from the left ("to the right" is understood... where else are you > going to go from the left?). > > I'm not going to quibble over what "left" is, nor what processing > something from the left to right means. If that's not understood between > us, then we don't have enough basis to discuss that aspect. > > But I would like to point out that: the fact that it is a source of > confusion only brings to the surface the imprecision of its name. > > On Thursday, December 15, 2016 at 1:05:14 PM UTC-6, Janis Voigtländer > wrote: >> >> 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. > -- 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.
