Data.Map.mapKeysMonotonic is a misleading name

Elliot Cameron eacameron at gmail.com
Thu Apr 4 22:43:34 UTC 2019


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

On Thu, Apr 4, 2019 at 3:57 PM Andreas Abel <andreas.abel at ifi.lmu.de> wrote:

> 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>
> >     <
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190404/2c068799/attachment.html>


More information about the Libraries mailing list