Proposal and discussion: Deprecate Data.Set.mapMonotonic and Data.Map.mapKeysMonotonic; add correctly named functions
Andreas Abel
abela at chalmers.se
Tue Jul 12 14:32:26 UTC 2016
+1 That would be consistent ;) (in some sense at least).
On 12.07.2016 07:49, David Feuer wrote:
> Fine. Sounds like I lose this one. Should the duals be mapAntitone and
> mapKeysAntitone?
>
> On Jul 12, 2016 1:44 AM, "Edward Kmett" <ekmett at gmail.com
> <mailto:ekmett at gmail.com>> wrote:
>
> I'm also slightly biased against renaming, as the intent is signaled
> pretty clearly.
>
> -Edward
>
> On Mon, Jul 11, 2016 at 6:12 AM, Andreas Abel <abela at chalmers.se
> <mailto:abela at chalmers.se>> wrote:
>
> I thought the current functions are quite clear with a bit of
> common sense. They assume the renaming of keys does not change
> their relative order, so the underlying tree structure of the
> map/set can remain as-is.
>
> Of course, as you point out, the names are not precise, but
> cannot the documentation add what is not reflected in the names?
>
> The question is, as always, if the breakage caused by the
> renaming compensates for having the optimal name. I am slightly
> biased against the renaming.
>
> --Andreas
>
>
> On 09.07.2016 02:28, David Feuer wrote:
>
>
> On Jul 8, 2016 7:18 PM, "Ivan Lazar Miljenovic"
> <ivan.miljenovic at gmail.com
> <mailto:ivan.miljenovic at gmail.com>
> <mailto:ivan.miljenovic at gmail.com
> <mailto:ivan.miljenovic at gmail.com>>> wrote:
> >
> > On 9 July 2016 at 03:49, 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>>> wrote:
>
> > > Data.Set: mapStrictlyIncreasing and mapStrictlyDecreasing
> > > Data.Map: mapKeysStrictlyIncreasing and
> mapKeysStrictlyDecreasing
> >
> > With the latter function also flipping the underlying
> tree structure?
>
> I'm not quite sure what you mean, but I think the answer is yes.
>
> mapKeysStrictlyDecreasing (\x -> -x) (fromList [1..10]) ===
> fromList
> [(-10) .. (-1)]
>
> >
> > > Data.Map presents another possibility, however. We
> could make the
> > > replacements more general, giving them types
> > >
> > > Ord k => (k -> v -> (k', v')) -> Map k v -> Map k' v'
> > >
> > > and allowing the user to map over both keys and values
> in one pass.
> >
> > Though IIUC this provides no way of specifying that "I'm
> sure this
> > function has a 1-1 monotonic relationship so you can
> just update the
> > keys without changing the structure" (in the sense of
> there's no way
> > to distinguish between the increasing and decreasing sense).
>
> That is the pre-condition. There still needs to be one for
> strictly
> increasing functions and another for strictly decreasing
> ones, since
> they lead to reversed tree structures.
>
> >
> > Overall, I'm about +0.5 from the naming sense of the current
> > functions, but have used these in the past.
>
> I don't understand this statement.
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <mailto:Libraries at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
> --
> Andreas Abel <>< Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> andreas.abel at gu.se <mailto:andreas.abel at gu.se>
> http://www2.tcs.ifi.lmu.de/~abel/
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <mailto:Libraries at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
--
Andreas Abel <>< Du bist der geliebte Mensch.
Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden
andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/
More information about the Libraries
mailing list