Add 'lookup' function to Data.Set #291
Conversation
* WHAT? This commit contains the implementation of a proposal to add a 'lookup' function on 'Set' in the "containers" package. The function > lookup :: Ord a => a -> Set a -> Maybe a is almost indentical to the 'member' function but, in addition, returns the value stored in the set. * WHY? The point of this proposal is to facilitate program-wide data sharing. The 'lookup' function gives access to a pointer to an object already stored in a Set and equal to a given argument. The 'lookup' function is a natural extension to the current 'lookupLT', 'lookupGT', 'lookupLE' and 'lookupGE' functions, with obvious semantics. Example use case: In a parser, the memory footprint can be reduced by collapsing all equal strings to a single instance of each string. To achieve this, one needs a way to get a previously seen string (internally, a pointer) equal to a newly parsed string. Amazingly, this is very difficult with the current "containers" library interface. One current option is to use a Map instead, e.g., 'Map String String' which stores twice as many pointers as necessary. * HOW? The git commit contains the straight-forward implementation of the 'lookup' function on 'Set', with test cases.
|
Unless someone comes up with a better name, or a good reason to dislike this one, I'd like to go with @andreasabel's suggestion of |
|
Could you also add a similar function to |
|
@m-renaud In the library list discussion, several people thought this was a bad idea. I believe that included @wrengr. They thought this sort of interning operation would be best handled by another data structure. Nothing about this is at all relevant to |
|
The mailing list discussion thread begins with https://mail.haskell.org/pipermail/libraries/2016-June/027116.html |
Ahh, that makes sense.
Gotcha. Reading through the discussion it seems like everyone was okay with |
|
Go ahead.
…On Dec 26, 2017 1:01 PM, "Matt Renaud" ***@***.***> wrote:
Nothing about this is at all relevant to Data.IntMap or Data.IntSet
Ahh, that makes sense.
The main dispute on the libraries list had to do with the name
Gotcha. Reading through the discussion it seems like everyone was okay
with lookupEntry as you mention in your comment above. The only
hesitation was that for sets the term "entry" doesn't existing in the
vocabulary. Should we start a new thread with a proposal with the functions
to make sure everyone is on board still?
lookupEntry :: Ord a => a -> Set a -> Maybe a
lookupEntry :: Ord k => k -> Map k v -> Maybe (k, v)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#291 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABzi_YV4bsgzz2LU3skO4iqZdhmTVaUgks5tETRfgaJpZM4I_hrB>
.
|
|
Giving this some more thought, why add Also, since "entry" is really parlance related to maps, removing this from Map means we could use the more appropriate term "elem(ent)": WDYT? |
|
The purpose for maps would be to extract the exact stored key. The keys in
the map correspond to the ones in a set; values are extra.
…On Dec 26, 2017 2:04 PM, "Matt Renaud" ***@***.***> wrote:
Giving this some more thought, why add lookupEntry for Data.Map? Map
already has lookup :: k -> Map k v -> Maybe v, so if you really wanted
you could implement Map.lookupEntry k m = (\v -> (k,v)) <$> lookup k m
without loss of performance.
Also, since "entry" is really parlance related to maps, removing this from
Map means we could use the more appropriate term "elem(ent)": lookupElement
:: (Ord a) => Set a -> Maybe a.
WDYT?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#291 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABzi_dr9VSErn8BIqMP-C0E3dd8K-DjZks5tEUMxgaJpZM4I_hrB>
.
|
Thanks for the clarification; I retract my previous comment. I'll go ahead and send a proposal to libraries for the two |
Did that libraries proposal ever happen? |
sjakobi
added
Set
needs-libraries-proposal
This is an implementation of the proposal submitted as Issue #290, but not yet discussed on the Haskell libraries list.