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

[David Feuer]

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> 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> 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/693d4d03/attachment.html>