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

Add filterKeys for Map and IntMap #972

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

flip111
Copy link

@flip111 flip111 commented Sep 23, 2023

@treeowl
Copy link
Contributor

treeowl commented Sep 27, 2023

Please don't include your Stack files. While I won't require it, I would prefer to see validity tests and also property tests (with validity tests) added both for filterKeys and filterWithKey. Also, CI is failing.

@flip111
Copy link
Author

flip111 commented Sep 30, 2023

Hello. The stack files i committed accidentally in my last commit. I will try to fix the test again

@meooow25
Copy link
Contributor

meooow25 commented Oct 1, 2023

We have

filter p m = filterWithKey (\_ x -> p x) m

So why not

filterKeys p m = filterWithKey (\k _ -> p k) m

instead of duplicating the definition of filterWithKey?

@konsumlamm
Copy link
Contributor

I don't see the advantage of this over just using filterWithKey?

@flip111
Copy link
Author

flip111 commented Dec 29, 2023

It's the equivalent of filter but then for keys

@konsumlamm
Copy link
Contributor

Sure, I know what it does, but why should we add it, when we can just use filterWithKey, which isn't any slower, instead?

@flip111
Copy link
Author

flip111 commented Dec 31, 2023

I can't speak for the original poster @emilypi but for my point of view is that haskell libraries have many convenience functions that potentially can be expressed in terms of extra functions. With filterWithKey you have an additional argument that is not used (when using it like filterKeys).

@emilypi
Copy link
Member

emilypi commented Dec 31, 2023

@flip111 that's exactly it. filterKeys is something many people do, and so we should optimize for it. The point is convenience. It's very low cost to add it, and i would argue it meets my personal Fairbarn threshold due to the fact that every other container library in existence features it.

@konsumlamm
Copy link
Contributor

every other container library in existence features it.

Really? I don't think I've ever seen it anywhere, could you give some examples?

@emilypi
Copy link
Member

emilypi commented Dec 31, 2023

Some examples:

  • guava
  • kotlin
  • scala - alternatively, view the deprecated version which used to act on the map itself.
  • purescript
  • clojure - they have a general policy of only supplying O(1) functions in the core libraries (one would have to issue (apply dissoc <f> <map>), but alternative cores supply this like the ones linked.
  • C++ experimental - there are many stack overflow questiosn regarding this function, and the current state of the non-experimental art is to write a for-loop which removes keys iteratively using std::map::erase.

There are many more examples, but I don't want to spend too much time on it. I don't see a valid argument against this other than "why not use filterWithKey", which has been addressed, and is largely a subjective for both sides. I've written this function alot, and I'd like to stop the repetition 😄

@PPKFS
Copy link

PPKFS commented Dec 31, 2023

This seems like something that:

  • is useful
  • is no added overhead
  • is not some obscurely named and cryptic to understand function
  • sure, it can be done already with filterWithKey or some equivalent but writing filterWithKey (f . snd) feels very strange - or should we be working in favour of removing every function that is just a more specific form of another function?

@Melvar
Copy link

Melvar commented Dec 31, 2023

I wanted this function a couple weeks ago. Of course I just used filterWithKey, but I had to check for the absence of filterKeys first.

Copy link
Contributor

@treeowl treeowl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seem to be enough people who want this to overcome my general reluctance to add semi-unnecessary functions to this package. I want some documentation and testing tweaks for both versions, even though I only added line comments to one.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We seem to be missing property tests for filterWithKey and filter as well as the new function. The one for filterWithKey should look something like this:

prop_filterWithKey :: Fun (Int, Int) Bool -> IMap -> Property
prop_filterWithKey fun m =
  valid m' .&&. toList m' === Prelude.filter (apply fun) (toList m)
  where
    m' = filterWithKey (apply2 fun) m

The others should be similar, with appropriate tweaks.

Copy link
Member

@emilypi emilypi Jan 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we implement filterKeys in terms of filterWithKey, that'd be great, but if we end up with the duplicate definition we currently have, I'd also want some tests for fidelity between the two a la

prop_filterKeysFidelity :: Fun Int Bool -> IMap -> Property
prop_filterKeysFidelity p m = fwk === fk 
  where
    fwk = filterWithKey (\k _ -> apply p k) m
    fk = filterKeys (apply p) m

containers/src/Data/IntMap/Internal.hs Show resolved Hide resolved
@flip111
Copy link
Author

flip111 commented Mar 17, 2024

@treeowl @emilypi any more comments? I made some changes after your review.

-- > filterKeys (> 4) == filterWithKey (\k _ -> k > 4)

filterKeys :: (Key -> Bool) -> IntMap a -> IntMap a
filterKeys predicate = filterWithKey (\k _ -> predicate k)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice :)

@emilypi
Copy link
Member

emilypi commented Mar 17, 2024

Looks fine to me, but it's up to @treeowl

@flip111
Copy link
Author

flip111 commented Apr 16, 2024

@treeowl could you take a look please? Is there anything i can do or something that needs to be done?

Comment on lines +96 to +106
-- pFilterKeys :: Fun (Int, Int) Bool -> IMap -> Property
-- pFilterKeys fun m =
-- valid m' .&&. toList m' === Prelude.filter (apply fun) (toList m)
-- where
-- m' = filterKeys (apply2 fun) m

-- pFilter :: Fun (Int, Int) Bool -> IMap -> Property
-- pFilter fun m =
-- valid m' .&&. toList m' === Prelude.filter (apply fun) (toList m)
-- where
-- m' = filter (apply2 fun) m
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean to add these? Currently they are commented out.

Comment on lines +90 to +94
pFilterWithKey :: Fun (Int, Int) Bool -> IMap -> Property
pFilterWithKey fun m =
valid m' .&&. toList m' === Prelude.filter (apply fun) (toList m)
where
m' = filterWithKey (apply2 fun) m
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move property tests to intmap-properties.hs.

Comment on lines +823 to +824
test_filterKeys :: Assertion
test_filterKeys = filterKeys (> 4) (fromList [(5,"a"), (3,"b")]) @?= singleton 5 "a"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not used, it needs to be added to the list of tests above.

, testCase "filterKeys" test_filterKeys

Also, it would be good to have property tests (like for IntMap).

-- | \(O(n)\). Filter all keys that satisfy the predicate.
--
-- > filterKeys (> 4) (fromList [(5,"a"), (3,"b")]) == singleton 5 "a"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a @since FIXME at the end of the docs. It will be updated by maintainers to the next release version.
Same for IntMap.

@meooow25 meooow25 mentioned this pull request Oct 31, 2024
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants