Skip to content
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

foldr1 and foldl1 are too restrictive #151

Open
natefaubion opened this issue May 16, 2022 · 1 comment
Open

foldr1 and foldl1 are too restrictive #151

natefaubion opened this issue May 16, 2022 · 1 comment
Labels
type: breaking change A change that requires a major version bump.

Comments

@natefaubion
Copy link
Contributor

natefaubion commented May 16, 2022

Should the signature of foldr1 (and similarly foldl1) be:

foldr1 :: forall f a b. Foldable1 f => (a -> b -> b) -> (a -> b) -> f a -> b

I understand the logic behind the current signature:

foldr1 :: forall f a b. Foldable1 f => (b -> b -> b) -> f b -> b

In that, if I have a mapping from a -> b, then I can pre-map unconditionally, and derive the latter signature. Unfortunately that's not actually what I want to do:

  • I only want the mapping to apply to the terminal value.
  • I want to otherwise combine with the combining function.
  • I don't want to waste an entire traversal to make the signature work.

I feel like there's a missed opportunity with the current signature. To be honest, I almost never want the current signature.

@JordanMartinez JordanMartinez added the type: breaking change A change that requires a major version bump. label May 17, 2022
@JordanMartinez
Copy link
Contributor

I'd be ok with making a breaking change release outside of the compiler changes. However, how would that be handled?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: breaking change A change that requires a major version bump.
Projects
None yet
Development

No branches or pull requests

2 participants