Re: Argument order for Data.Map.adjustF

Fair enough. -Edward On Thu, May 19, 2016 at 8:30 PM, David Feuer wrote:

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.

...

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

On Sat, May 7, 2016 at 4:45 PM, David Feuer wrote: 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