<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>