On 14 July 2016 at 22:45, Jake McArthur wrote:

I like the function, but I'd like to bikeshed a bit. The name "restriction" seems confusing to me, or at least I don't understand the etymology. As of now I'd prefer something like "filterMember". filterMember is to (filter . flip member) as concatMap is to (concat . map). That's not perfectly consistent due to the flip, but I think it's close enough to motivate the name.

More possible bikeshed colours: * intersectionWith/setIntersection to reflect the similarity with the existing intersection functions * restrictTo (which may fit better with the proposed argument order than the ones above) If we keep this argument order, then I think a name similar to restriction as originally proposed makes more sense than an intersection one (as the arguments are flipped compared to the other similarly named functions).

On Thu, Jul 14, 2016, 5:39 AM Andreas Abel wrote:

...

+1.

On 14.07.2016 06:45, David Feuer wrote:

...

Cale Gibbard proposes the following:

Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a

In each case, the map is filtered to contain only the keys that are also found in the set. This can be implemented efficiently using a slightly stripped-down version of Data.Map.intersection.

David Feuer _______________________________________________ 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

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

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

I've also needed this in the past, so +1. I think the bike-shed should be colored: intersectKeys or restrictKeys -Iavor On Thu, Jul 14, 2016 at 6:39 AM, Edward Kmett wrote:

+1 on the functionality, not a fan of the name.

Bikeshed color: intersectionWithSet?

-Edward

On Thu, Jul 14, 2016 at 9:36 AM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

...

...

I like the function, but I'd like to bikeshed a bit. The name "restriction" seems confusing to me, or at least I don't understand the etymology. As of now I'd prefer something like "filterMember". filterMember is to (filter . flip member) as concatMap is to (concat . map). That's not perfectly consistent due to the flip, but I think it's close enough to motivate

On 14 July 2016 at 22:45, Jake McArthur wrote: the

...

name.

More possible bikeshed colours:

* intersectionWith/setIntersection to reflect the similarity with the existing intersection functions

* restrictTo (which may fit better with the proposed argument order than the ones above)

If we keep this argument order, then I think a name similar to restriction as originally proposed makes more sense than an intersection one (as the arguments are flipped compared to the other similarly named functions).

...

On Thu, Jul 14, 2016, 5:39 AM Andreas Abel wrote:

...

+1.

On 14.07.2016 06:45, David Feuer wrote:

...

Cale Gibbard proposes the following:

Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a

In each case, the map is filtered to contain only the keys that are also found in the set. This can be implemented efficiently using a slightly stripped-down version of Data.Map.intersection.

David Feuer _______________________________________________ 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

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

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Restricting the domain of a function is common terminology in maths. I like the original name 'restrict' or 'restrictTo' or 'restrictKeys'. Intersection is a symmetric operation, so that name is less suitable, imho. On 14.07.2016 17:41, amindfv@gmail.com wrote:

+1 to the function, +1 to 'restrictKeys' or 'intersectKeys'

Tom

El 14 jul 2016, a las 11:01, Iavor Diatchki mailto:iavor.diatchki@gmail.com> escribió:

...

I've also needed this in the past, so +1.

I think the bike-shed should be colored: intersectKeys or restrictKeys

-Iavor

On Thu, Jul 14, 2016 at 6:39 AM, Edward Kmett mailto:ekmett@gmail.com> wrote:

+1 on the functionality, not a fan of the name.

Bikeshed color: intersectionWithSet?

-Edward

On Thu, Jul 14, 2016 at 9:36 AM, Ivan Lazar Miljenovic mailto:ivan.miljenovic@gmail.com> wrote:

On 14 July 2016 at 22:45, Jake McArthur mailto:jake.mcarthur@gmail.com> wrote: > I like the function, but I'd like to bikeshed a bit. The name "restriction" > seems confusing to me, or at least I don't understand the etymology. As of > now I'd prefer something like "filterMember". filterMember is to (filter . > flip member) as concatMap is to (concat . map). That's not perfectly > consistent due to the flip, but I think it's close enough to motivate the > name.

More possible bikeshed colours:

* intersectionWith/setIntersection to reflect the similarity with the existing intersection functions

* restrictTo (which may fit better with the proposed argument order than the ones above)

If we keep this argument order, then I think a name similar to restriction as originally proposed makes more sense than an intersection one (as the arguments are flipped compared to the other similarly named functions).

> > > On Thu, Jul 14, 2016, 5:39 AM Andreas Abel mailto:abela@chalmers.se> wrote: >> >> +1. >> >> On 14.07.2016 06:45, David Feuer wrote: >> > Cale Gibbard proposes the following: >> > >> > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a >> > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a >> > >> > In each case, the map is filtered to contain only the keys that are >> > also found in the set. This can be implemented efficiently using a >> > slightly stripped-down version of Data.Map.intersection. >> > >> > David Feuer >> > _______________________________________________ >> > Libraries mailing list >> > Libraries@haskell.org mailto: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 mailto:andreas.abel@gu.se >> http://www2.tcs.ifi.lmu.de/~abel/ >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org mailto:Libraries@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org mailto:Libraries@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com mailto:Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com _______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto: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/

On Thu, Jul 14, 2016 at 8:01 AM, Iavor Diatchki wrote:

I've also needed this in the past, so +1.

I think the bike-shed should be colored: intersectKeys or restrictKeys

+1 for intersectKeys. I already have to look up Data.Map haddock constantly (e.g. alter vs. adjust), but intersectKeys is nicely self descriptive.

If you name it, it will come! On Jul 14, 2016 11:55 AM, "Ross Paterson" wrote:

On Thu, Jul 14, 2016 at 12:45:27AM -0400, David Feuer wrote:

...

Cale Gibbard proposes the following:

Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a

In each case, the map is filtered to contain only the keys that are also found in the set. This can be implemented efficiently using a slightly stripped-down version of Data.Map.intersection.

One might also want the counterpart of Data.Map.difference for similar reasons. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote:

If you name it, it will come!

intersectKeys and differentiateKeys or intersectionWithSet and differenceWithSet or ;) intersectionOfKeys and differenceOfKeys Greetings, Daniel

I got distracted from this discussion for a bit. Based on input from the list, and Ross Paterson's remark about argument order, I'm currently thinking restrictKeys :: Ord k => Map k a -> Set k -> Map k a and withoutKeys :: Ord k => Map k a -> Set k -> Map k a Are there any major objections? On Thu, Jul 14, 2016 at 12:54 PM, Alexey Vagarenko wrote:

How about `keepKeys`?

2016-07-14 21:36 GMT+05:00 Daniel Trstenjak :

...

On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote:

...

If you name it, it will come!

intersectKeys and differentiateKeys

or

intersectionWithSet and differenceWithSet

or ;)

intersectionOfKeys and differenceOfKeys

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

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

A final question: Both `restrictKeys` and `withoutKeys` are special cases of `filterWithKey` (although they should be considerably more efficient than implementations using that function). Do we also want a `partition` special case, in which a map is partitioned into the keys that are in a set and the ones that are not? On Mon, Jul 25, 2016 at 1:10 PM, Edward Kmett wrote:

Good enough for me.

On Mon, Jul 25, 2016 at 12:11 PM, David Feuer wrote:

...

I got distracted from this discussion for a bit. Based on input from the list, and Ross Paterson's remark about argument order, I'm currently thinking

restrictKeys :: Ord k => Map k a -> Set k -> Map k a

and

withoutKeys :: Ord k => Map k a -> Set k -> Map k a

Are there any major objections?

On Thu, Jul 14, 2016 at 12:54 PM, Alexey Vagarenko wrote:

...

How about `keepKeys`?

2016-07-14 21:36 GMT+05:00 Daniel Trstenjak :

...

On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote:

...

If you name it, it will come!

intersectKeys and differentiateKeys

or

intersectionWithSet and differenceWithSet

or ;)

intersectionOfKeys and differenceOfKeys

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

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

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

I'm not sure yet, but I suspect it might be possible to implement partitionByKeySet more efficiently than the naive way. But to do so, it will have to construct both pieces eagerly, meaning that using only part of its result will waste time and allocation. On Mon, Jul 25, 2016 at 3:34 PM, Andreas Abel wrote:

Seems like the partition function would subsume the others?!

partitionByKeys :: Ord k => Set k -> Map k a -> (Map k a, Map k a)

Would there be impressive speed gains for a native

fst . partitionByKeys set

?

On 25.07.2016 20:59, David Feuer wrote:

...

A final question:

Both `restrictKeys` and `withoutKeys` are special cases of `filterWithKey` (although they should be considerably more efficient than implementations using that function). Do we also want a `partition` special case, in which a map is partitioned into the keys that are in a set and the ones that are not?

On Mon, Jul 25, 2016 at 1:10 PM, Edward Kmett wrote:

...

Good enough for me.

On Mon, Jul 25, 2016 at 12:11 PM, David Feuer wrote:

...

I got distracted from this discussion for a bit. Based on input from the list, and Ross Paterson's remark about argument order, I'm currently thinking

restrictKeys :: Ord k => Map k a -> Set k -> Map k a

and

withoutKeys :: Ord k => Map k a -> Set k -> Map k a

Are there any major objections?

On Thu, Jul 14, 2016 at 12:54 PM, Alexey Vagarenko wrote:

...

How about `keepKeys`?

2016-07-14 21:36 GMT+05:00 Daniel Trstenjak :

...

On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote: > > If you name it, it will come!

intersectKeys and differentiateKeys

or

intersectionWithSet and differenceWithSet

or ;)

intersectionOfKeys and differenceOfKeys

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

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

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

_______________________________________________ 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

Given the fragility of rewrite rules (and the fact that they don't happen at all at the default optimization level) that seems too delicate of a solution to endorse. That doesn't prevent us from adding the rewrite rules to try to help existing code that already uses filter (`S.member` set), in addition to these combinators, though. That idiom is already rather common given the lack of an alternative to date and improving its performance wouldn't hurt. -Edward On Mon, Jul 25, 2016 at 6:05 PM, Joachim Breitner wrote:

Hi,

Am Montag, den 25.07.2016, 14:59 -0400 schrieb David Feuer:

...

Both `restrictKeys` and `withoutKeys` are special cases of `filterWithKey` (although they should be considerably more efficient than implementations using that function).

I’m risking to derailing this discussion, but how viable would it be to *not* add a new exported name for this, but recommend (e.g. in the docs) to use

filter (`S.elem` set) map

and then rely on rewrite rules to get the desired performance effect (by rewriting this expression to an non-exported restrictKeys)?

I guess the answer is: Not viable enough, because rewrite rules are not applied reliably enough, and because you cannot easily have the effect of a partial "map `restrictKeys`". But nevertheless it is an interesting idea to imagine a programming language where APIs can be minimal, modular and composable without performance penalties.

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

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

On Mon, Jul 25, 2016 at 9:11 AM, David Feuer wrote:

I got distracted from this discussion for a bit. Based on input from the list, and Ross Paterson's remark about argument order, I'm currently thinking

restrictKeys :: Ord k => Map k a -> Set k -> Map k a

and

withoutKeys :: Ord k => Map k a -> Set k -> Map k a

Are there any major objections?

+1 for this color of bikeshed. (and +1 to having the bikeshed, regardless of color) -- Live well, ~wren