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

[Edward Kmett]

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> 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>> 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/
>
> _______________________________________________
> Libraries mailing list
> 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/20160712/3c3e1a78/attachment.html>