<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I guess I just want names to say what they mean and not require me to deduce what they must mean based on other, possibly invisible, constraints. If we can come up with a good name for this then I'd even be happier if we simply added an alias with a less-confusing name and didn't even formally deprecate the other one. Can some suggest such a name? I've tossed a few out: mapKeysInjectiveIncreasing, mapKeysStrictlyIncreasing, mapKeysMonotonicDistinct</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 4, 2019 at 3:57 PM Andreas Abel <<a href="mailto:andreas.abel@ifi.lmu.de">andreas.abel@ifi.lmu.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Elliot,<br>
<br>
Maybe as a German I do not stumble over that use of "monotonic" in the <br>
same way as you might. In German, we have<br>
<br>
  <= monoton steigend<br>
  >= monoton fallend<br>
  < streng monoton steigend<br>
  > streng monoton fallend<br>
<br>
Thus, "monoton" by itself is not a precise notion, but refers to the <br>
family of these concepts (although it is a bit sloppily often used for <br>
"monoton steigend"). The German precise name of mapKeysMonotonic would be<br>
<br>
  transformiereSchlüsselStrengMonotonSteigend<br>
<br>
and you can see that using fully precise names get you nowhere in my <br>
context. :D<br>
<br>
However, my question still stands what else than "strictly increasing" <br>
could be meant in "mapKeysMonotonic"? If it is not an injective <br>
function you pass to it, then what can be the advantage over the general <br>
"mapKeysWith"? And how likely is the case that a <br>
"mapKeysNonStrictlyIncreasing" would be preferable over "mapKeysWith", <br>
justifying the extra implementation of a "mapKeysNonStrictlyIncreasing"?<br>
<br>
Cheers,<br>
Andreas<br>
<br>
On 2019-04-04 16:58, Elliot Cameron wrote:<br>
> Thanks Artyom. That's useful. In fact in highlights the original <br>
> motivation for my request. Data.Map his numerous wrappers and clones (I <br>
> happened to be working on monoidal-containers) and this name keeps <br>
> getting spread throughout them. In the case of a monoidal-containers, <br>
> mapKeysMonotonic only makes sense with a Semigroup constraint on the <br>
> values (because a monotonic function can still cause keys to get <br>
> merged). But now the name is even more confusing: what happens to <br>
> duplicate keys: are they merged with Data.Map's infamous left-bias? Are <br>
> they <>ed together? But that can't be since there is no Semigroup <br>
> constraint... Your search shows that this same name is also used in <br>
> IntervalMap and Agda for the very reason that it matches the name in <br>
> Data.Map!<br>
> <br>
> So my true hope is that a) people won't be confused by this function and <br>
> b) people will stop using this name in wrappers/clones if it's not <br>
> /actually/Â the appropriate name.<br>
> <br>
> On Thu, Apr 4, 2019 at 9:51 AM Artyom Kazak <<a href="mailto:yom@artyom.me" target="_blank">yom@artyom.me</a> <br>
> <mailto:<a href="mailto:yom@artyom.me" target="_blank">yom@artyom.me</a>>> wrote:<br>
> <br>
>Â Â Â It's not used _very_ often, but it does appear a few times on<br>
>Â Â Â Hackage. For instance, it's used several times in Agda source:<br>
>Â Â Â <a href="https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+%7C$)&insensitive=off&space=off&precise=off&sources=on&page=1" rel="noreferrer" target="_blank">https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+|$)&insensitive=off&space=off&precise=off&sources=on&page=1</a><br>
>Â Â Â <<a href="https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+%7C$)&insensitive=off&space=off&precise=off&sources=on&page=1" rel="noreferrer" target="_blank">https://codesearch.aelve.com/haskell/search?query=.mapKeysMonotonic&filter=Data.Map(+%7C$)&insensitive=off&space=off&precise=off&sources=on&page=1</a>><br>
> <br>
>Â Â Â On Apr 4 2019, at 3:19 pm, Andreas Abel <<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a><br>
>Â Â Â <mailto:<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a>>> wrote:<br>
> <br>
>Â Â Â Â Â > I doubt this function is used very often.<br>
> <br>
>Â Â Â Â Â You could be mistaken. Me, too. Without statistical data, I have 0<br>
>Â Â Â Â Â confidence in such estimates of brain 1.<br>
>Â Â Â Â Â <a href="https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow</a><br>
> <br>
>Â Â Â Â Â On 2019-04-04 14:46, Elliot Cameron wrote:<br>
> <br>
>Â Â Â Â Â Â Â Well I'm proposing deprecation not removal. The deprecation<br>
>Â Â Â Â Â Â Â could even<br>
>Â Â Â Â Â Â Â live forever for all I care. It would point to the new name<br>
>Â Â Â Â Â Â Â as well. Not<br>
>Â Â Â Â Â Â Â to mention I doubt this function is used very often.<br>
> <br>
>Â Â Â Â Â Â Â On Thu, Apr 4, 2019, 2:58 AM Andreas Abel<br>
>Â Â Â Â Â Â Â <<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a> <mailto:<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a>><br>
>Â Â Â Â Â Â Â <mailto:<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a><br>
>Â Â Â Â Â Â Â <mailto:<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a>>>> wrote:<br>
> <br>
>Â Â Â Â Â Â Â I am not sure this subtlety is worth the breakage and<br>
>Â Â Â Â Â Â Â annoyance to<br>
>Â Â Â Â Â Â Â users<br>
>Â Â Â Â Â Â Â coming with the name change.<br>
>Â Â Â Â Â Â Â If you think about it, renaming the keys while preserving<br>
>Â Â Â Â Â Â Â the tree<br>
>Â Â Â Â Â Â Â structure cannot work if two old keys map to the same new key.<br>
> <br>
>Â Â Â Â Â Â Â On 2019-04-03 17:13, Elliot Cameron wrote:<br>
> <br>
>Â Â Â Â Â Â Â Â Â Yeah the clearest names seem to be really long ones:<br>
>Â Â Â Â Â Â Â Â Â mapKeysMonotonicDistinct, mapKeysInjectiveIncreasing,<br>
>Â Â Â Â Â Â Â Â Â mapKeysReferToDocs, etc.<br>
> <br>
>Â Â Â Â Â Â Â Â Â On Wed, Apr 3, 2019 at 11:11 AM David Feuer<br>
> <br>
>Â Â Â Â Â Â Â <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a> <mailto:<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>><br>
>Â Â Â Â Â Â Â <mailto:<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a> <mailto:<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>>><br>
> <br>
>Â Â Â Â Â Â Â Â Â <mailto:<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a><br>
>Â Â Â Â Â Â Â Â Â <mailto:<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>><br>
>Â Â Â Â Â Â Â Â Â <mailto:<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a><br>
>Â Â Â Â Â Â Â Â Â <mailto:<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>>>>> wrote:<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â We can't use "increasing" because mathematically<br>
>Â Â Â Â Â Â Â Â Â that usually<br>
> <br>
>Â Â Â Â Â Â Â means<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â non-strictly increasing. Using "ascending" gets us<br>
>Â Â Â Â Â Â Â Â Â in trouble<br>
> <br>
>Â Â Â Â Â Â Â with<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â the other functions in the module that use the<br>
>Â Â Â Â Â Â Â Â Â word in a<br>
> <br>
>Â Â Â Â Â Â Â non-strict<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â sense.<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â On Wed, Apr 3, 2019, 10:46 AM Elliot Cameron<br>
> <br>
>Â Â Â Â Â Â Â <<a href="mailto:eacameron@gmail.com" target="_blank">eacameron@gmail.com</a> <mailto:<a href="mailto:eacameron@gmail.com" target="_blank">eacameron@gmail.com</a>><br>
>Â Â Â Â Â Â Â <mailto:<a href="mailto:eacameron@gmail.com" target="_blank">eacameron@gmail.com</a> <mailto:<a href="mailto:eacameron@gmail.com" target="_blank">eacameron@gmail.com</a>>><br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â <mailto:<a href="mailto:eacameron@gmail.com" target="_blank">eacameron@gmail.com</a><br>
>Â Â Â Â Â Â Â Â Â <mailto:<a href="mailto:eacameron@gmail.com" target="_blank">eacameron@gmail.com</a>> <mailto:<a href="mailto:eacameron@gmail.com" target="_blank">eacameron@gmail.com</a><br>
>Â Â Â Â Â Â Â Â Â <mailto:<a href="mailto:eacameron@gmail.com" target="_blank">eacameron@gmail.com</a>>>>> wrote:<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â Hello!<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â In some recent analysis I ran into a subtlety<br>
>Â Â Â Â Â Â Â Â Â that caught<br>
> <br>
>Â Â Â Â Â Â Â me by<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â surprise: Data.Map.mapKeysMonotonic has a<br>
>Â Â Â Â Â Â Â Â Â misleading name.<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â A monotonic function is not a strictly<br>
>Â Â Â Â Â Â Â Â Â /increasing/Â function,<br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â but merely non-decreasing. However,<br>
> <br>
>Â Â Â Â Â Â Â |mapKeysMonotonic|Â requires<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â that it's mapping function be injective, which<br>
>Â Â Â Â Â Â Â Â Â means it<br>
> <br>
>Â Â Â Â Â Â Â really<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â only supports /increasing/Â functions.<br>
> <br>
>              valid (mapKeysMonotonic (\x-> if x`elem` <br>
>         [1,2]then 2<br>
> <br>
>       else x) (fromList [(1,"a"), (2,"b"), (3,"c")]))== False<br>
> <br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â The docs hint at this with "This means that @f<br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â <<a href="https://github.com/f" rel="noreferrer" target="_blank">https://github.com/f</a>>@ maps distinct original<br>
>Â Â Â Â Â Â Â Â Â keys to<br>
> <br>
>Â Â Â Â Â Â Â distinct<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â resulting keys."<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â However, I'd propose that we deprecate this<br>
>Â Â Â Â Â Â Â Â Â name and<br>
> <br>
>Â Â Â Â Â Â Â rename to<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â something like |mapKeysIncreasing|or<br>
>Â Â Â Â Â Â Â Â Â |mapKeysAsc|Â (to<br>
> <br>
>Â Â Â Â Â Â Â follow the<br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â pattern of other *Asc functions). We should<br>
>Â Â Â Â Â Â Â Â Â also clarify<br>
> <br>
>Â Â Â Â Â Â Â the docs.<br>
> <br>
> <br>
> <br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â From<br>
>Â Â Â Â Â Â Â Â Â <a href="https://github.com/haskell/containers/issues/617" rel="noreferrer" target="_blank">https://github.com/haskell/containers/issues/617</a><br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â _______________________________________________<br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â Libraries mailing list<br>
>Â Â Â Â Â Â Â Â Â <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>><br>
>Â Â Â Â Â Â Â Â Â <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
>Â Â Â Â Â Â Â Â Â <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>>><br>
> <br>
>Â Â Â Â Â Â Â <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>><br>
>Â Â Â Â Â Â Â <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>>>><br>
> <br>
>Â Â Â Â Â Â Â Â Â <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
> <br>
> <br>
>Â Â Â Â Â Â Â Â Â _______________________________________________<br>
>Â Â Â Â Â Â Â Â Â Libraries mailing list<br>
>Â Â Â Â Â Â Â Â Â <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>><br>
>Â Â Â Â Â Â Â Â Â <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
>Â Â Â Â Â Â Â Â Â <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>>><br>
>Â Â Â Â Â Â Â Â Â <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
> <br>
>Â Â Â Â Â Â Â _______________________________________________<br>
>Â Â Â Â Â Â Â Libraries mailing list<br>
>Â Â Â Â Â Â Â <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>><br>
>Â Â Â Â Â Â Â <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>>><br>
>Â Â Â Â Â Â Â <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
> <br>
>Â Â Â Â Â _______________________________________________<br>
>Â Â Â Â Â Libraries mailing list<br>
>Â Â Â Â Â <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>><br>
>Â Â Â Â Â <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
> <br>
</blockquote></div>