Proposal and discussion: Deprecate Data.Set.mapMonotonic and Data.Map.mapKeysMonotonic; add correctly named functions

[Andreas Abel]

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>> wrote:
>  >
>  > On 9 July 2016 at 03:49, David Feuer <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
> 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/