Argument order for Data.Map.adjustF

[Edward Kmett]

Fair enough.

-Edward

On Thu, May 19, 2016 at 8:30 PM, David Feuer <david.feuer at gmail.com> 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.
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160520/27aca5a0/attachment.html>