Argument order for Data.Map.adjustF

[Edward Kmett]

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 <david.feuer at 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