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 unsafe functions for converting between Set and Map #818

Open
josephcsible opened this issue Feb 2, 2022 · 3 comments
Open

Add unsafe functions for converting between Set and Map #818

josephcsible opened this issue Feb 2, 2022 · 3 comments

Comments

@josephcsible
Copy link
Contributor

In #814, @treeowl asked for functions like these:

unsafeToSet :: (k -> a -> b) -> Map k a -> Set b
unsafeToMap :: (b -> (k, a)) -> Set b -> Map k a

And also ones that live in an Applicative, which I assume means ones like these:

unsafeToSetA :: Applicative t => (k -> a -> t b) -> Map k a -> t (Set b)
unsafeToMapA :: Applicative t => (b -> t (k, a)) -> Set b -> t (Map k a)

Note the lack of Ord constraints: these functions are unsafe in that it's the user's responsibility to make sure the k and b values agree on their ordering, just as it is for mapMonotonic. I think those are reasonable functions to add, but a little bit out of scope of that issue, hence this one.

josephcsible added a commit to josephcsible/containers that referenced this issue Jul 25, 2022
@alexfmpe
Copy link
Contributor

Maybe we could instead have 'smaller' building blocks?

toSet :: Map k a -> Set (Arg k a)
toMap :: Set (Arg k a) -> Map k a

that can then be composed with other ones to generate all the variants?

unsafeToSet :: (k -> a -> b) -> Map k a -> Set b
unsafeToSet f = Set.mapMonotonic (\(Arg k a) -> f k a) . toSet
unsafeToMap :: (b -> (k, a)) -> Set b -> Map k a
unsafeToMap f = toMap . Set.mapMonotonic (uncurry Arg . f)

This isomorphism might also be useful elsewhere actually

@josephcsible
Copy link
Contributor Author

@alexfmpe Hah, see #817 and #814 (comment)

@alexfmpe
Copy link
Contributor

Oh nevermind, you already stated all that in #814 (comment) .

I thought containers avoided functions that were easily derivable from already exposed ones (unless a specialized version was more efficient) to keep the API small?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants