Data.Map.mapKeysMonotonic is a misleading name
Andreas Abel
andreas.abel at ifi.lmu.de
Thu Apr 4 19:57:48 UTC 2019
Elliot,
Maybe as a German I do not stumble over that use of "monotonic" in the
same way as you might. In German, we have
<= monoton steigend
>= monoton fallend
< streng monoton steigend
> streng monoton fallend
Thus, "monoton" by itself is not a precise notion, but refers to the
family of these concepts (although it is a bit sloppily often used for
"monoton steigend"). The German precise name of mapKeysMonotonic would be
transformiereSchlüsselStrengMonotonSteigend
and you can see that using fully precise names get you nowhere in my
context. :D
However, my question still stands what else than "strictly increasing"
could be meant in "mapKeysMonotonic"? If it is not an injective
function you pass to it, then what can be the advantage over the general
"mapKeysWith"? And how likely is the case that a
"mapKeysNonStrictlyIncreasing" would be preferable over "mapKeysWith",
justifying the extra implementation of a "mapKeysNonStrictlyIncreasing"?
Cheers,
Andreas
On 2019-04-04 16:58, Elliot Cameron wrote:
> 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
> <mailto: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
> <mailto: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>
> <mailto: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>>
>
> <mailto: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>>
>
> <mailto: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>>
>
> <mailto: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>
> <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>
> <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
>
More information about the Libraries
mailing list