Open Martoon-00 opened 2 years ago
Additionally, I'd like to include
groupByKeyOn
—it's less general, but it avoids those explicit preconditions by leaning on Eq.
I also like how *On
version would go without preconditions on the provided function.
My thought on not including it was that other packages seem to avoid the addition of *On
version unless it does something special compared to passing mere on
call (i.e. there is no groupOn f = groupBy ((==) 'on' f)
).
Other examples: sortOn
which has slightly different performance characteristics and non-existing Data.List.NonEmpty.groupOn
.
So I think if we go with adding groupByKeyOn
, we should be consistent and add mere groupOn
too, but this is likely the work for a separate issue.
What do you think?
I would like to have it for all the things. Sorting is weird because of sortOn f
vs. sortBy (compare `on` f)
. I don't know if any of the other common functions have both options. I don't think these ones do.
Okay, added On
versions for grouping, and sorting is out of scope of this issue.
@treeowl Requesting the final review :eyes:
Description
I often witnessed the need in
[(a, b)] -> [(a, [b])]
grouping function, so adding it here since we are working on similar things in-parallel.Related issues(s)
✓ Checklist for your Pull Request
Ideally a PR has all of the checkmarks set.
If something in this list is irrelevant to your PR, you should still set this checkmark indicating that you are sure it is dealt with (be that by irrelevance).
Related changes (conditional)
Tests
Documentation
I checked whether I should update the docs and did so if necessary:
Record your changes
Stylistic guide (mandatory)
[x] My commit history is clean (only contains changes relating to my issue/pull request and no reverted-my-earlier-commit changes) and commit messages start with identifiers of related issues in square brackets.
Example:
[#42] Short commit description
If necessary both of these can be achieved even after the commits have been made/pushed using rebase and squash.