Proposal for containers: Add 'pop' function to Data.Map
Andreas Abel
andreas.abel at ifi.lmu.de
Sun Dec 6 18:38:11 UTC 2020
I have reservations against this proposal:
1. `pop` seems to be below the Fairbairn threshold.
> pop :: Int -> IntMap a -> (Maybe a, IntMap a)
> pop = updateLookupWithKey (\_ _ -> Nothing)
It specializes the Swiss knife `updateLookupWithKey` without involving
any other map-specific function.
2. Addition of `pop` would require a similar function in all other
standard collections, to keep their interfaces in sync.
3. Is there sufficient evidence that `pop` is a strongly user-demanded
feature? One way to quantify this is to look on hackage for the pattern
`updateLookupWithKey (\_ _ -> Nothing)` (and variants) and maybe even on
how often this pattern has been given a name.
(The latter would be a more scientific way to develop our libraries in
general. Instead of randomly adding functionality based on
non-representative discussions on this list, we could scan hackage for
common patterns---especially, mine popular utility libraries. Harvest
the intelligence of the masses...)
While I would not recommend to add `pop`, I would recommend to enhance
the documentation of `updateLookupWithKey` to include `pop` as a use
case. This would also ensure the discoverability of the present solution.
I seem to recall that we have given this recommendation to similar
proposals in the past ("similar" in terms of the Fairbairn threshold).
Cheers,
Andreas
On 2020-12-06 19:04, Oleg Grenrus wrote:
> NonEmptySeq could be. NonEmptySet almost (it could have extract).
>
> - Oleg
>
> On 6.12.2020 20.02, David Feuer wrote:
>> None of these types are comonads, so it doesn't seem *that* confusing.
>>
>> On Sun, Dec 6, 2020, 12:59 PM Bob Ippolito <bob at redivi.com
>> <mailto:bob at redivi.com>> wrote:
>>
>> `extract` overlaps with the Comonad typeclass (extract, duplicate,
>> extend)
>>
>> On Sun, Dec 6, 2020 at 9:34 AM Tom Ellis
>> <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk
>> <mailto:tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>> wrote:
>>
>> I really like `extract`!
>>
>> On Sun, Dec 06, 2020 at 05:29:40PM +0000, Alexey Kuleshevich
>> wrote:
>> > `extract` is the name that I would suggest. I also agree
>> with David
>> > that `pop` is a bit too confusing in a non-stack/queue data
>> > structure. If all languages named it pop, then it would be good
>> > argument for the name, but we don't need to copy python. The
>> only
>> > thing that pyhon has that I wish we had in Haskell is the
>> popularity
>> > ;)
>> >
>> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> > On Sunday, December 6, 2020 8:16 PM, Carter Schonwald
>> <carter.schonwald at gmail.com
>> <mailto:carter.schonwald at gmail.com>> wrote:
>> >
>> > > LookupThenRemove seems like a more descriptive name.
>> Though I guess I can see why pop has appeal.
>> > >
>> > > On Sun, Dec 6, 2020 at 11:44 AM David Feuer
>> <david.feuer at gmail.com <mailto:david.feuer at gmail.com>> wrote:
>> > >
>> > >> I suggest you add a version for Data.Sequence combining
>> lookup with deleteAt. I wanted that for something fairly recently.
>> > >>
>> > >> On Sun, Dec 6, 2020, 11:41 AM Martijn Bastiaan via
>> Libraries <libraries at haskell.org
>> <mailto:libraries at haskell.org>> wrote:
>> > >>
>> > >>> Yeah, Python's `pop` made me call it `pop`. I had hoped
>> to find other
>> > >>> examples, but Java, Rust, and Ruby don't seem to offer
>> `pop`-like
>> > >>> functions for their (hash)maps.
>> > >>>
>> > >>> On 12/6/20 5:29 PM, Tom Ellis wrote:
>> > >>>> On Sun, Dec 06, 2020 at 11:25:33AM -0500, David Feuer
>> wrote:
>> > >>>>> The name pop makes me think of a stack. Is this use of
>> the word common?
>> > >>>> Python uses that name, which is why I'm familiar with it:
>> > >>>>
>> > >>>>>>> d = {'a': 1, 'b': 2}
>> > >>>>>>> d.pop('b')
>> > >>>> 2
>> > >>>>>>> d
>> > >>>> {'a': 1}
>> > >>>> _______________________________________________
>> > >>>> Libraries mailing list
>> > >>>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>> > >>>>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>> > >>> _______________________________________________
>> > >>> Libraries mailing list
>> > >>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>> > >>>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>> > >>
>> > >> _______________________________________________
>> > >> Libraries mailing list
>> > >> Libraries at haskell.org <mailto:Libraries at haskell.org>
>> > >>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>>
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org <mailto:Libraries at haskell.org>
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> <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
>
More information about the Libraries
mailing list