Data.Map.mapKeysMonotonic is a misleading name

[Elliot Cameron]

Thanks Artyom. That's useful. In fact in highlights the original motivation
for my request. Data.Map his numerous wrappers and clones (I happened to be
working on monoidal-containers) and this name keeps getting spread
throughout them. In the case of a monoidal-containers, mapKeysMonotonic
only makes sense with a Semigroup constraint on the values (because a
monotonic function can still cause keys to get merged). But now the name is
even more confusing: what happens to duplicate keys: are they merged with
Data.Map's infamous left-bias? Are they <>ed together? But that can't be
since there is no Semigroup constraint... Your search shows that this same
name is also used in IntervalMap and Agda for the very reason that it
matches the name in Data.Map!

So my true hope is that a) people won't be confused by this function and b)
people will stop using this name in wrappers/clones if it's not *actually* the
appropriate name.

On Thu, Apr 4, 2019 at 9:51 AM Artyom Kazak <yom at artyom.me> wrote:

> It's not used _very_ often, but it does appear a few times on Hackage. For
> instance, it's used several times in Agda source:
> https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+|$)&insensitive=off&space=off&precise=off&sources=on&page=1
> <https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+%7C$)&insensitive=off&space=off&precise=off&sources=on&page=1>
>
> On Apr 4 2019, at 3:19 pm, Andreas Abel <andreas.abel at ifi.lmu.de> wrote:
>
> > I doubt this function is used very often.
>
> You could be mistaken. Me, too. Without statistical data, I have 0
> confidence in such estimates of brain 1.
> https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow
>
> On 2019-04-04 14:46, Elliot Cameron wrote:
>
> Well I'm proposing deprecation not removal. The deprecation could even
> live forever for all I care. It would point to the new name as well. Not
> to mention I doubt this function is used very often.
>
> On Thu, Apr 4, 2019, 2:58 AM Andreas Abel <andreas.abel at ifi.lmu.de
> <mailto:andreas.abel at ifi.lmu.de>> wrote:
>
> I am not sure this subtlety is worth the breakage and annoyance to
> users
> coming with the name change.
> If you think about it, renaming the keys while preserving the tree
> structure cannot work if two old keys map to the same new key.
>
> On 2019-04-03 17:13, Elliot Cameron wrote:
>
> Yeah the clearest names seem to be really long ones:
> mapKeysMonotonicDistinct, mapKeysInjectiveIncreasing,
> mapKeysReferToDocs, etc.
>
> On Wed, Apr 3, 2019 at 11:11 AM David Feuer
>
> <david.feuer at gmail.com <mailto:david.feuer at gmail.com>
>
> <mailto:david.feuer at gmail.com <mailto:david.feuer at gmail.com>>> wrote:
>
>      We can't use "increasing" because mathematically that usually
>
> means
>
>      non-strictly increasing. Using "ascending" gets us in trouble
>
> with
>
>      the other functions in the module that use the word in a
>
> non-strict
>
>      sense.
>
>      On Wed, Apr 3, 2019, 10:46 AM Elliot Cameron
>
> <eacameron at gmail.com <mailto:eacameron at gmail.com>
>
>      <mailto:eacameron at gmail.com <mailto:eacameron at gmail.com>>> wrote:
>
>          Hello!
>
>          In some recent analysis I ran into a subtlety that caught
>
> me by
>
>          surprise: Data.Map.mapKeysMonotonic has a misleading name.
>
>          A monotonic function is not a strictly /increasing/ function,
>          but merely non-decreasing. However,
>
> |mapKeysMonotonic| requires
>
>          that it's mapping function be injective, which means it
>
> really
>
>          only supports /increasing/ functions.
>
>          valid (mapKeysMonotonic (\x->  if  x`elem`  [1,2]then  2
>
> else  x) (fromList [(1,"a"), (2,"b"), (3,"c")]))==  False
>
>
>          The docs hint at this with "This means that @f
>          <https://github.com/f>@ maps distinct original keys to
>
> distinct
>
>          resulting keys."
>
>          However, I'd propose that we deprecate this name and
>
> rename to
>
>          something like |mapKeysIncreasing|or |mapKeysAsc| (to
>
> follow the
>
>          pattern of other *Asc functions). We should also clarify
>
> the docs.
>
>
>
>           From https://github.com/haskell/containers/issues/617
>          _______________________________________________
>          Libraries mailing list
> Libraries at haskell.org <mailto:Libraries at haskell.org>
>
> <mailto:Libraries at haskell.org <mailto:Libraries at haskell.org>>
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <mailto:Libraries at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <mailto:Libraries at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> 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/20190404/78d5d90e/attachment.html>