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

[David Feuer]

It feels very awkward to me.

On Sun, Dec 6, 2020, 5:59 PM Philip Hazelden <philip.hazelden at gmail.com>
wrote:

> Hm. I note that with `minView` and `uncons`, moving the Maybe to the
> inside doesn't increase the space of return values. That is, any input that
> gives `Nothing` now would give `(Nothing, empty)` if Maybe was on the
> inside. That's not true of this function; if the key isn't found, that
> doesn't tell us what is in the map. Of course it tells us that the second
> part of the return value is the same as the input map, but that feels not
> super-close to "the second part of the return value is this one specific
> value".
>
> And, my sense is that having Maybe on the inside would be more often what
> people would want to use. Like... if you don't care what the
> map-without-this-element looks like, you'd just use lookup. So clearly the
> caller of this function is going to use it in some cases.
> Maybe-on-the-outside is fine if you'll use it "only if the element was
> already there", but seems likely awkward otherwise.
>
> So I'd argue for keeping the Maybe on the inside.
>
> On Sun, Dec 6, 2020 at 7:42 PM Simon Jakobi via Libraries <
> libraries at haskell.org> wrote:
>
>> Regarding the type signature:
>>
>> pop :: Ord k => k -> Map k a -> (Maybe a, Map k a)
>>
>> I think it might be better to be consistent with similar functions like
>>
>> minView :: Map k a -> Maybe (a, Map k a)
>>
>> and
>>
>> uncons :: [a] -> Maybe (a, [a])
>>
>> Therefore the type should be
>>
>> pop :: Ord k => k -> Map k a -> Maybe (a, Map k a)
>>
>> ---
>>
>> I like the "pop" name though – I think the analogy to stacks is pretty
>> obvious.
>>
>> ---
>>
>> Like Andreas Abel I believe, that if there is a good, simple
>> implementation, it might be a good first step to simply document the
>> implementation as an example.
>>
>> If there's much demand for exporting the function or if a fast
>> implementation is more complex, we can still enhance the API later on.
>>
>>
>> Am So., 6. Dez. 2020 um 17:20 Uhr schrieb Martijn Bastiaan via
>> Libraries <libraries at haskell.org>:
>> >
>> > Hi all,
>> >
>> > Proposal:
>> >
>> >    * Add `pop` and `popWithDefault` to `Data.Map` and `Data.IntMap`.
>> >    * See https://github.com/haskell/containers/pull/757 for exact
>> definition
>> >
>> > Why:
>> >
>> >    * They're useful functions I expected to be in `Data.Map` and
>> >      `Data.IntMap`. (This might be influenced by the fact that
>> >      they're defined on Python's `dict`.)
>> >
>> >    * Their implementations (~ `updateLookupWithKey (\_ _ -> Nothing)`)
>> >      are harder to parse than a simple `pop`, which should help Haskell
>> >      codebases become a bit cleaner :).
>> >
>> >    * Their implementations are a bit non-obvious. My first instinct was
>> >      to write `(Map.lookup ..., Map.delete ...)`, which would have done
>> >      two traversals. Having "properly" implemented functions in the lib
>> >      would prevent people from writing their own suboptimal ones.
>> >
>> > Details and implementation:
>> >
>> >    * https://github.com/haskell/containers/pull/757
>> >
>> > Kind regards,
>> > Martijn Bastiaan
>> > _______________________________________________
>> > 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/20201206/9475f59a/attachment.html>