<html><head></head><body>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'.<br>—<br>Sent from my phone with K-9 Mail.<br><br><div class="gmail_quote">On December 6, 2020 11:30:15 PM UTC, David Feuer <david.feuer@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="auto">It feels very awkward to me.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 6, 2020, 5:59 PM Philip Hazelden <<a href="mailto:philip.hazelden@gmail.com">philip.hazelden@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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".<br></div><div><br></div><div>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.</div><div><br></div><div>So I'd argue for keeping the Maybe on the inside.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 6, 2020 at 7:42 PM Simon Jakobi via Libraries <<a href="mailto:libraries@haskell.org" target="_blank" rel="noreferrer">libraries@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Regarding the type signature:<br>
<br>
pop :: Ord k => k -> Map k a -> (Maybe a, Map k a)<br>
<br>
I think it might be better to be consistent with similar functions like<br>
<br>
minView :: Map k a -> Maybe (a, Map k a)<br>
<br>
and<br>
<br>
uncons :: [a] -> Maybe (a, [a])<br>
<br>
Therefore the type should be<br>
<br>
pop :: Ord k => k -> Map k a -> Maybe (a, Map k a)<br>
<br>
---<br>
<br>
I like the "pop" name though – I think the analogy to stacks is pretty obvious.<br>
<br>
---<br>
<br>
Like Andreas Abel I believe, that if there is a good, simple<br>
implementation, it might be a good first step to simply document the<br>
implementation as an example.<br>
<br>
If there's much demand for exporting the function or if a fast<br>
implementation is more complex, we can still enhance the API later on.<br>
<br>
<br>
Am So., 6. Dez. 2020 um 17:20 Uhr schrieb Martijn Bastiaan via<br>
Libraries <<a href="mailto:libraries@haskell.org" target="_blank" rel="noreferrer">libraries@haskell.org</a>>:<br>
><br>
> Hi all,<br>
><br>
> Proposal:<br>
><br>
> * Add `pop` and `popWithDefault` to `Data.Map` and `Data.IntMap`.<br>
> * See <a href="https://github.com/haskell/containers/pull/757" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell/containers/pull/757</a> for exact definition<br>
><br>
> Why:<br>
><br>
> * They're useful functions I expected to be in `Data.Map` and<br>
> `Data.IntMap`. (This might be influenced by the fact that<br>
> they're defined on Python's `dict`.)<br>
><br>
> * Their implementations (~ `updateLookupWithKey (\_ _ -> Nothing)`)<br>
> are harder to parse than a simple `pop`, which should help Haskell<br>
> codebases become a bit cleaner :).<br>
><br>
> * Their implementations are a bit non-obvious. My first instinct was<br>
> to write `(Map.lookup ..., Map.delete ...)`, which would have done<br>
> two traversals. Having "properly" implemented functions in the lib<br>
> would prevent people from writing their own suboptimal ones.<br>
><br>
> Details and implementation:<br>
><br>
> * <a href="https://github.com/haskell/containers/pull/757" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell/containers/pull/757</a><br>
><br>
> Kind regards,<br>
> Martijn Bastiaan<br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div></body></html>