-
Notifications
You must be signed in to change notification settings - Fork 49
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
Exposing functions using defaults from a Monoid
constraint
#124
Comments
I'm yet not convinced about usefulness of Take for example:
And to make it sure, I'm 👎 to use |
Well, I've seen this pattern a few times. But most of the time it is done by using some combination of In the end it's just 2 functions without any invasive change. I don't see the point in not adopting them. (The naming was just a proposal.)
I don't see the point of your example. Also I would argue that you should rather point out why it shouldn't be adopted in general. Most definitions are not useful in every context, that doesn't mean they are never useful.
Why would you ever want to limit yourself to instances of |
There are various places in this module where it might be useful to have padding for containers that happen to contain
Monoid
al values be automatically defaulted bymempty
.I'm particularly thinking of something like:
padZipEmpty :: (Semialign f, Monoid a, Monoid b) => f a -> f b -> f (a,b)
padZipWithEmpty :: (Semialign f, Monoid a, Monoid b) => (a -> b -> c) -> f a -> f b -> f c
Perhaps it might also be worth exposing an explicit default version too:
padZipDef :: (Semialign f) => a -> b -> f a -> f b -> f (a,b)
Let me know what you think. I'm happy to implement this and send a PR if you like the idea.
The text was updated successfully, but these errors were encountered: