Proposal: Add `restriction` to Data.Map and Data.IntMap
amindfv at gmail.com
amindfv at gmail.com
Thu Jul 14 15:41:02 UTC 2016
+1 to the function, +1 to 'restrictKeys' or 'intersectKeys'
Tom
> El 14 jul 2016, a las 11:01, Iavor Diatchki <iavor.diatchki at 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 <ekmett at 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 <ivan.miljenovic at gmail.com> wrote:
>>> On 14 July 2016 at 22:45, Jake McArthur <jake.mcarthur at 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 <abela at 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 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
>>> >
>>> >
>>> > _______________________________________________
>>> > Libraries mailing list
>>> > Libraries at haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>> >
>>>
>>>
>>>
>>> --
>>> Ivan Lazar Miljenovic
>>> Ivan.Miljenovic at gmail.com
>>> http://IvanMiljenovic.wordpress.com
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> 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/20160714/b0a47545/attachment-0001.html>
More information about the Libraries
mailing list