<p dir="ltr">To add to the summary, we also considered a function to insert an element into a set or a pair into a map preserving the existing key. For maps, we'd want a variant of insertWithKey, I suppose. TBH, I find the current insertion behavior perplexing. Perhaps it would make sense to add modules with more sensible insertion functions? How much risk is there of breaking things by changing the behavior of the current functions to *preserve* elements/keys rather than replacing them, and making insertWithKey give the passed function the stored key rather than the given one?</p>
<div class="gmail_quote">On Jul 4, 2016 11:32 AM, "Nicolas Godbout" <<a href="mailto:nicolas.godbout@gmail.com">nicolas.godbout@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Here is recap of the numerous answers to this proposal one week into voting.<br>
As a reminder, the original proposal is to add the following to Data.Set<br>
<br>
    lookup :: Ord a => a -> Set a -> Maybe a<br>
<br>
There is essentially unconditional support for inclusion of such a function. The debate centers around the name given to the function. There were quite a number of +1 votes for the ‘lookup’ name as is. There were also quite a number of valid objections, in particular from the "containers" package containers. The final name will _not_ be 'lookup', it remains to decide what the name is.<br>
<br>
The following names have been floated so far, together with opinions (expressed on the list and my own).<br>
<br>
* lookupEQ<br>
    pro: it fits in the lookupGT, lookupLT, lookupGE, lookupLE  cluster of existing Data.Set functions<br>
    con: the cluster set of functions have atypical names and don't seem to generate any enthusiasm on the list<br>
<br>
* find<br>
    pro: closer to the semantics, similar to Data.Map.findWithDefault<br>
    con: nothing to do with the signature of Data.List.find<br>
In my opinion, this one is dead.<br>
<br>
* lookupSharedPointer, lookupWithSharing, lookupIntern<br>
    pro: express the intention of returning a pointer to enable sharing<br>
    con: new pattern for libraries, explicitly mentions pointers which is decidedly un-Haskell-like<br>
My strong vote goes to eliminating these. Pointer behaviour is fairly obvious to expert Haskellers, but should not be mentioned to beginners. Let them ask on the Haskell mailing list why there is a 'lookup'-like function on Sets and let us just briefly mention the sharing behavior in the Haddock docs.<br>
<br>
* lookupEntry, lookupKey, lookupWithKey<br>
   pro: These names are in the spirit of "container" functions.<br>
   con: In the case of 'Entry', it introduces a new concept distinct from a member or element.<br>
These are the names deserving discussion and voting. There is already a (+1) for 'lookupEntry'<br>
It was mentioned that a pattern emerges with 'insertWithKey', 'adjustWithKey', 'updateWithKey' functions from Data.Map<br>
     > lookupWithKey :: Ord k => k -> Map a -> Maybe (k,a)<br>
suggesting the current proposal to converge to<br>
     > lookupWithKey :: Ord a => a -> Set a -> Maybe a<br>
<br>
As a side note, it was noted in several replies that all relevant "container" lookup functions should come with the guarantee that the copy from the container is returned. I vote (+1) on that!<br>
<br>
My personal take on the current matter is that whatever we choose should be compatible with Data.List.<br>
    > lookup??? :: Ord a => [a] -> a -> Maybe a<br>
    > lookup??? :: Ord a => a -> Set a -> Maybe a<br>
    > lookup??? :: Ord k => k -> Map k a -> Maybe (k,a)<br>
where the element returned is the one from the container, enabling sharing. This kills the name 'lookup' since it is already taken in Data.List. What seems to make the most sense is 'lookupEntry', which defines the concept of 'entry' as whatever is logically stored in the container. A Map is therefore defined as logically storing key-value pairs, exactly as in an association list.<br>
<br>
+1 on 'lookupEntry'<br>
<br>
<br>
Nicolas.<br>
<br>
<br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>