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