Proposal for containers: Add 'lookup' function to Data.Set

[David Feuer]

I think it bears mentioning that there's no need to discuss pointers to
explain these functions. == in general may be coarser than structural
equality, since most interesting data structures can represent the same
abstract object in more than one way. So we need only explain that the
result is the element stored in the set that is == to the requested value.
On Jul 4, 2016 11:32 AM, "Nicolas Godbout" <nicolas.godbout at gmail.com>
wrote:

>
> Here is recap of the numerous answers to this proposal one week into
> voting.
> As a reminder, the original proposal is to add the following to Data.Set
>
>     lookup :: Ord a => a -> Set a -> Maybe a
>
> 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.
>
> The following names have been floated so far, together with opinions
> (expressed on the list and my own).
>
> * lookupEQ
>     pro: it fits in the lookupGT, lookupLT, lookupGE, lookupLE  cluster of
> existing Data.Set functions
>     con: the cluster set of functions have atypical names and don't seem
> to generate any enthusiasm on the list
>
> * find
>     pro: closer to the semantics, similar to Data.Map.findWithDefault
>     con: nothing to do with the signature of Data.List.find
> In my opinion, this one is dead.
>
> * lookupSharedPointer, lookupWithSharing, lookupIntern
>     pro: express the intention of returning a pointer to enable sharing
>     con: new pattern for libraries, explicitly mentions pointers which is
> decidedly un-Haskell-like
> 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.
>
> * lookupEntry, lookupKey, lookupWithKey
>    pro: These names are in the spirit of "container" functions.
>    con: In the case of 'Entry', it introduces a new concept distinct from
> a member or element.
> These are the names deserving discussion and voting. There is already a
> (+1) for 'lookupEntry'
> It was mentioned that a pattern emerges with 'insertWithKey',
> 'adjustWithKey', 'updateWithKey' functions from Data.Map
>      > lookupWithKey :: Ord k => k -> Map a -> Maybe (k,a)
> suggesting the current proposal to converge to
>      > lookupWithKey :: Ord a => a -> Set a -> Maybe a
>
> 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!
>
> My personal take on the current matter is that whatever we choose should
> be compatible with Data.List.
>     > lookup??? :: Ord a => [a] -> a -> Maybe a
>     > lookup??? :: Ord a => a -> Set a -> Maybe a
>     > lookup??? :: Ord k => k -> Map k a -> Maybe (k,a)
> 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.
>
> +1 on 'lookupEntry'
>
>
> Nicolas.
>
>
>
> _______________________________________________
> 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/20160704/663e2ae3/attachment.html>