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

[Keith]

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
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20201207/51d3fa36/attachment.html>