New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`foldl` and `foldr` different from Haskell's? #956

Closed
Spaxe opened this Issue Apr 21, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@Spaxe

Spaxe commented Apr 21, 2018

I'm curious why Elm's implementation of foldl and foldr has identical signatures, where as Haskell's doesn't.

For example:

Elm: foldl : (a -> b -> b) -> b -> List a -> b

Haskell: foldl :: (b -> a -> b) -> b -> [a] -> b

Source code: https://github.com/elm-lang/core/blob/master/src/List.elm#L148-L184

@evancz

This comment has been minimized.

Show comment
Hide comment
@evancz

evancz Apr 21, 2018

Member

Elm does it like Standard ML, and I always thought that was nicer. So the real question is why did Haskell do something different than Standard ML? ;)

The short version is that (1) I find it so much easier to remember just one thing, (2) we say "the data structure is always the last argument" is a good guide to writing functions and that means our type fits better with other functions in the language, and (3) I think the "oh, but math" argument ignores these practical considerations.

I recommend asking for more info on the Elm slack if you are still curious! We try to keep issues for bug tracking and community forums for learning, and they can give nice answers more efficiently!

Member

evancz commented Apr 21, 2018

Elm does it like Standard ML, and I always thought that was nicer. So the real question is why did Haskell do something different than Standard ML? ;)

The short version is that (1) I find it so much easier to remember just one thing, (2) we say "the data structure is always the last argument" is a good guide to writing functions and that means our type fits better with other functions in the language, and (3) I think the "oh, but math" argument ignores these practical considerations.

I recommend asking for more info on the Elm slack if you are still curious! We try to keep issues for bug tracking and community forums for learning, and they can give nice answers more efficiently!

@evancz evancz closed this Apr 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment