I do agree that it would be more consistent to use the alter ordering,
but I don't see many users who will reach for it as "generalized
alter".
Ultimately, I anticipate the major consumers of such a function would
be people using some lens package, either through us changing the
default definitions in lens to automatically use it on appropriate
versions of containers, or through using a more minimalist lens
package that doesn't provide lenses for containers -- most other
people will neither find the new operation nor care.
The former would require a flip for lens consumers to turn it back
into a lens, making it much harder to recognize as such.
-Edward
On Sat, May 7, 2016 at 4:45 PM, David Feuer
I managed to find an implementation of Control.Lens.At.at for Data.Map that's fast enough to be useful. The function will be named alterF to match the name of Data.Map.alter. The remaining question is what order the arguments should go in. I had thought to follow those of alter for consistency, giving
alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k a -> f (Map k a)
Edward Kmett thinks the ergonomics of that order are terrible, and prefers to follow lens at, giving
alterF :: (Functor f, Ord k) => k -> (Maybe a -> f (Maybe a)) -> Map k a -> f (Map k a)
How do other people feel about this?
David Feuer