Re: Proposal for containers: Add 'pop' function to Data.Map

Well said Andreas, I emphatically agree with your latter point: We need to ground proposal need / utility with statistical information about actual code out in the world. On Sun, Dec 6, 2020 at 1:38 PM Andreas Abel wrote:

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 mailto:bob@redivi.com> wrote:

`extract` overlaps with the Comonad typeclass (extract, duplicate, extend)

On Sun, Dec 6, 2020 at 9:34 AM Tom Ellis mailto:tom-lists-haskell-cafe-2017@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 mailto:carter.schonwald@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 mailto:david.feuer@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 mailto:libraries@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@haskell.org mailto:Libraries@haskell.org > >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries 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 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 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 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 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 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