What do you think of just providing one function hash-filter (or hash-filter/copy to be consistent with hash-map/copy)? The provided procedure would consume both key and value. That way, you only need one function instead of two.

What do you think of just providing one function hash-filter (or hash-filter/copy to be consistent with hash-map/copy)? The provided procedure would consume both key and value. That way, you only need one function instead of two.

While I agree it makes sense to have a function that consumes the key and value (hash-filter, hash-filter/copy), I do think it feels cleaner on the user side to still provide key-specific and value-specific keywords, i.e. providing hash-filter, hash-filter-keys, hash-filter-values. Putting the onus to handle both key and value in the provided lambda has lead me to default to the less ideal (map fn (hash-keys ht)) pattern in the past.

That said, I am open to whatever makes the most sense given the community and API philosophy in Racket, as I am still very new to the idea of adding functionality here

What do you think of just providing one function hash-filter (or hash-filter/copy to be consistent with hash-map/copy)? The provided procedure would consume both key and value. That way, you only need one function instead of two.

While I agree it makes sense to have a function that consumes the key and value (hash-filter, hash-filter/copy), I do think it feels cleaner on the user side to still provide key-specific and value-specific keywords, i.e. providing hash-filter, hash-filter-keys, hash-filter-values. Putting the onus to handle both key and value in the provided lambda has lead me to default to the less ideal (map fn (hash-keys ht)) pattern in the past.

That said, I am open to whatever makes the most sense given the community and API philosophy in Racket, as I am still very new to the idea of adding functionality here

I've updated the PR to include hash-filter and rewritten hash-filter-values/keys to use hash-filter

It seems weird to me that hash-filter would work on mutable hashes at all. Where I would think there would be 2 separate operations: hash-filter for immutable ones, and hash-filter! for mutable ones.

@AlexKnauth That's my first thought too, but there's hash-map/copy that works in a similar way, so I don't think it's too "weird".

@sorawee @AlexKnauth should I try splitting this up into hash-filter! for mutable hash tables and hash-filter for immutable hash tables, or is this fine as is? Alternatively, should I rename the current hash-filter to hash-filter/copy since it makes a copy, and then build out the previously mentioned hash-filter, hash-filter!?

hash-filter should not mutate the hash table it's given.

What is needed to move this forward?

I cannot merge it due to the merge conflicts. Can you pull the latest master, rebase your changes on top of it, squash them to one commit, and then force push?

Hi @sorawee @AlexKnauth , is there anything that still needs to be done here?

Sorry, looks good to me. Merged.

Thanks so much!

This PR broke the following package: https://plt.cs.northwestern.edu/pkg-build/server/built/fail/odysseus.txt

@sorawee @dr-neptune — ping

There's always the possibility of backward incompatibility when an export is added to a module. Our general rule is to add an export only when it does not create a conflict with any package registered at pkgs.racket-lang.org. (This is a compromise between a completely consistent approach to backward compatibility and practical evolution of APIs, since code not registered as a package can still break.) Usually, when there's a conflict, we just don't make the addition to the original library — which may mean noyt having the binding at all, or it may mean an extra library or submodule. Sometimes, the remedy is to get a helpful package author to change code. In any case, this needs to be resolved, since we're trying to get the v8.13 release out.

My apologies, I didn't see the previous ping by @samth . I'm not super familiar with this process. My first guess based on the error message is that the Odysseus package has some version of hash-filter. Would it make sense to try to supersede it with hash-filter in base racket/hash? Odysseus looks to be a general purpose helper library:

https://pkgs.racket-lang.org/package/odysseus

My thought is that filtering a hash makes sense in a std lib as opposed to a loaded external lib.

What do you think @mflatt @sorawee @prozion ?

raco setup: /home/root/user/.local/share/racket/snapshot/pkgs/odysseus/odysseus/optimize.rkt:7:9: module: identifier already required
raco setup: at: hash-filter
raco setup: in: "hash.rkt"
raco setup: also provided by: racket/hash

Also, given the time component I understand if it would be better to roll back this change and chat about it further to prioritize getting 8.13 out

The best solution is for prozion/odysseus#2 to get merged (thanks @AlexKnauth). If @prozion doesn't respond about that then maybe we need to change the name or revert the addition.

By April 16, if the odysseus PR is not merged, I think we should just revert this PR.

Let's revert the PR for now.