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] > <javascript:>>: > > 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] <javascript:>. > 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.
