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@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@gmail.com <mailto:ivan.miljenovic@gmail.com>> wrote:
 >
 > On 9 July 2016 at 03:49, David Feuer <david.feuer@gmail.com
<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