Re: Argument order for Data.Map.adjustF

This might be a good case for having two names for the same function. Both use cases seem reasonable, and I don't really want containers to be too opinionated about the style of code using it. On Sat, May 7, 2016, 7:59 PM Edward Kmett wrote:

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

...

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

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries