FWIW, I think we (Elm) got this one wrong, and Kasey is pointing out something totally right. I feel that now I understand more about the difference between left/right folding than I did before as a result of really trying to understand the point that Kasey is making.
On Thu, Dec 15, 2016 at 6:23 PM, Kasey Speakman <[email protected]> wrote: > Having the behavior you expect? So if you write List.foldl (++) "" ["a", > "b", "c"], you *expect* to get "cba"? This does not produce what you > visually see in the calling statement, nor what what is produced from by > common definition of left fold (in case you want to argue about common > definition, see above mentioned wikipedia article). How is that expected? > > I certainly could consult the documentation before writing any given > statement, but needing to do so to verify a common operation produces the > expected result is a symptom of a problem. > > This conversation is stagnating, saying the same things in different ways, > arguing semantics and word meanings. So if there's no new information in > the next post, the last word is yours. I do understand that your library > would be affected by such a change. But I wouldn't worry about it, as I > doubt this will get fixed anyway. In fact, it's this way because preference > trumped other concerns during design. No disrespect to Evan... we've all > been there. > > On Thursday, December 15, 2016 at 4:40:21 PM UTC-6, Janis Voigtländer > wrote: >> >> Well, both in terms of "described" and "expected", all it takes is to >> have a look at the function's type. I personally often don't care much >> about prose in function documentation. For this specific function, take a >> look at the type (the placement of "a"s and "b"s) and that together with >> the "l" mnemonic from the function's name describes pretty much exactly how >> list elements will be combined. Or am I overlooking right now another way >> in which a function of that polymorphic type could process a list from left >> to right while producing some output? >> >> And likewise, seeing that function signature and knowing that the >> function is not the/a right-fold, there is only exactly one behavior I >> would expect from it, and it's the one it indeed has. :-) >> >> (Of course, if the function had the implementation you want it to have, >> it would also have a different type, and that type would be equally >> descriptive for that other implementation's behavior, and would also raise >> exactly the correct expectations for that implementation.) >> >> Am 15.12.2016 um 23:13 schrieb Kasey Speakman <[email protected]>: >> >> It's not only a matter of preference, but getting the result that you >> expect from the statement. Whether you look at visual expansion or the way >> the operation is defined most other places, I'm not sure how it could be >> considered working as described much less working as expected. Maybe it is >> working as intended, but that's not a criteria I'm basing my statements on. >> >> On Thursday, December 15, 2016 at 3:04:31 PM UTC-6, Janis Voigtländer >> 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. >>>> >>> >>> I don't disagree with your preference for symmetry. I just pointed out >>> that if one considers processing order on the input (only), there is no >>> basis to say that Elm's foldl is wrong or not left-to-right. That one >>> should consider both input and output order/nesting when pondering the name >>> of this function seems not to have been a principle of the maker of that >>> decision. >>> >>> -- >> 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. > -- 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.
