Wren Romano and I have decided to maintain consistency in the argument
order, even though this is more annoying for people using lens. Thus

alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k
a -> f (Map k a)

and `Control.Lens.At.at` for maps can be implemented as

at = flip Data.Map.Lazy.alterF

Note that Data.Map.Strict will also offer a version of alterF that
forces any values it installs in the map.


On Sat, May 7, 2016 at 4:45 PM, David Feuer <david.feuer@gmail.com> wrote:

> 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