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

[David Feuer]

That's not a concern.

On Sun, Dec 6, 2020, 7:31 PM Keith <keith.wygant at gmail.com> wrote:

> Also, I'm not sure if this is a real concern, but holding a reference to
> the original Map seems more likely to leak memory that always using the
> 'new' map returned by 'popWithKey'.
> —
> Sent from my phone with K-9 Mail.
>
> On December 6, 2020 11:30:15 PM UTC, David Feuer <david.feuer at gmail.com>
> wrote:
>>
>> 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
>>>
>> _______________________________________________
> 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/0b6cda53/attachment.html>