Argument order for Data.Map.adjustF

[Jake McArthur]

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 <ekmett at gmail.com> 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
>
> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160511/a9e3e708/attachment.html>