Re: [elm-discuss] Re: fold function argument order

> > Having the behavior you expect? So if you write List.foldl (++) "" ["a", > "b", "c"], you *expect* to get "cba"? > Yes, if I looked at the type of List.foldl first (or still had it in mind). Which is exactly what my statement about "expected" was conditioned by. Not more, not less. -- You

Re: [elm-discuss] Re: fold function argument order

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

Re: [elm-discuss] Re: fold function argument order

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

Re: [elm-discuss] Re: fold function argument order

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"

Re: [elm-discuss] Re: fold function argument order

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

Re: [elm-discuss] Re: fold function argument order

> > 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

Re: [elm-discuss] Re: fold function argument order

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

Re: [elm-discuss] Re: fold function argument order

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,

Re: [elm-discuss] Re: fold function argument order

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

Re: [elm-discuss] Re: fold function argument order

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

Re: [elm-discuss] Re: fold function argument order

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

Re: [elm-discuss] Re: fold function argument order

Yes, I did confuse mathematically associativity with programming language associativity (which adds left and right distinctions for expression evaluation) in the previous post. I stand corrected. A mathematically associative operation will work from either left or right when folding. But a

Re: [elm-discuss] Re: fold function argument order

I do know how foldl is in other languages. And that it is different in those other languages than it is in Elm. And I even agree that it would be better that foldl in Elm is as in other languages (or Haskell, specifically). I think I even argued for this on this mailing list in the past. But all

Re: [elm-discuss] Re: fold function argument order

I read the associativity article. You should examine this wikipedia article on fold . OCaml, F#, Haskell, Scala, Clojure, Elixir, etc. all have left folds as described in this article. Elm does not. I included a quote from it below.

Re: [elm-discuss] Re: fold function argument order

Kasey, you keep talking as if there were a mathematical, semantic concept of “left-associativity” (and the same for “right-associativity”). But there isn’t. Or can you give a definition? A definition of the mathematical, semantic concept of “associativity” is: “An operator is associative if

Re: [elm-discuss] Re: fold function argument order

Minor term correction. String concatenation isn't left-associative (duh on my part). It's just not commutative (the order can't be swapped and still get the same answer, unlike addition/multi). On Friday, December 9, 2016 at 11:15:04 PM UTC-6, Kasey Speakman wrote: > > It's about associativity.

Re: [elm-discuss] Re: fold function argument order

It's about associativity. Some operations have specific associativity even when a and b are different types. Cons (::) is a great example of this. Cons is only right associative even when `a` is Int and `b` is List Int. You cannot write `[] :: 1 :: 2 :: 3`, because cons does not work from the

Re: [elm-discuss] Re: fold function argument order

Fold takes arguments in the same order as update: the element and then the accumulator. Don't trust partial application of infix ops unless you know they are commutative. Write a lambda instead. -- You received this message because you are subscribed to the Google Groups "Elm Discuss"

Re: [elm-discuss] Re: fold function argument order

expection to this exceptation. On Fri, Dec 9, 2016 at 2:17 PM, Nick H wrote: > I would disagree with "not expected in general." In general -- when a and > b are different types -- Elm's API design guidelines should set you up to > always expect a -> b -> b and never b

Re: [elm-discuss] Re: fold function argument order

I would disagree with "not expected in general." In general -- when a and b are different types -- Elm's API design guidelines should set you up to always expect a -> b -> b and never b -> a -> b. If the definition of foldl were changed to take the latter, it would be the only exception to this

Re: [elm-discuss] Re: fold function argument order

Ok, correction List.foldl (-) 0 [1, 2, 3] -- returns 2 -- expands to 3 - (2 - (1 - 0)) = 2 During my testing last night, I had a typo (foldr instead of foldl) when I was testing the expansions. That was the center-building behavior. Using the form a -> b -> b is right-building regardless of

Re: [elm-discuss] Re: fold function argument order

Sorry, that last bit was an example of what happens in Elm when folding with string concat (++). That's unexpected behavior from a left fold. List.foldl (++) "" ["The ", "quick ", "brown "] -- returns "brown quick The " On Friday, December 9, 2016 at 8:26:17 AM UTC-6, Kasey Speakman wrote: >

Re: [elm-discuss] Re: fold function argument order

You're confusing pipe's syntax and infix. Pipe is defined like this: (|>) x f = f x And used like this x |> f == f x So pipe has an inherent flip because it is used to chain otherwise right-building statements. e.g. List.sum (List.filter isOdd [1, 2, 3]) vs [1, 2, 3] |> List.filter isOdd

Re: [elm-discuss] Re: fold function argument order

What's confusing here is how currying works with infix operators. It's idiomatic in Elm to have your accumulator be the last argument, and, for instance, if you were writing your own data type, you would want to write your functions so that they can be chained together easily: myMatrix

[elm-discuss] Re: fold function argument order

(deleted and corrected original post with proper expansion of Elm's foldl) I know this is a really old thread, but I ran into this precise question and thought I would add a perspective. The form a -> b -> b is not left-building, regardless of the direction you are traversing the list. An

[elm-discuss] Re: fold function argument order

I know this is a really old thread, but I ran into this precise question and thought I would add a perspective. The form a -> b -> b actually makes the fold right-building, regardless of the direction you are traversing the list. An example: Starting from zero, subtract the numbers 1, 2, and