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

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 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" mailto:ivan.miljenovic@gmail.com> wrote:

...

On 9 July 2016 at 03:49, David Feuer

mailto:david.feuer@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@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@gu.se http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries