I also would not care for a foldHeadToTail function where the order of operations is unspecified. It would be unusable without knowing the order in some cases. I was just pointing out that it's more accurate to foldl's implementation, considering the modern body of work that already implements foldl differently.
On Thursday, December 15, 2016 at 1:57:57 PM UTC-6, Kasey Speakman wrote: > > The two examples you provide, the first is left-to-right on *both* input > and output. The other (Elm's) is not. Right fold is right-to-left on > *both* input and output. The lack of symmetry between the two operations > only reinforces the issue. > > On Thursday, December 15, 2016 at 1:51:26 PM UTC-6, Janis Voigtländer > wrote: >> >> 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.
