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

[Alec]

`lookupEntry` seems fine to me...

\begin{bikeshedding}
but it bugs me a little that (according to the API) Sets have "members"
(`member`, `notMember`, and `splitMember`) and "elems" (`elems`, `elemAt`),
but (at least as of yet) no "entries".  (In my brief scan of the docs, it
appears "element" is the preferred English for "thing that can be in a
Set").  Andreas' suggestion applies the name to Map as well, so I buy that
"entry" is actually a new notion distinct from "element" or "member"---but
if a user isn't expected to have that notion in mind when seeking this
functionality, it seems mildly disadvantageous to introduce a new word for
"thing that can be in a Set" to the API.
\end{bikeshedding}

On Wed, Jun 29, 2016 at 5:18 PM David Feuer <david.feuer at gmail.com> wrote:

> Let me be firm (co-maintainer's prerogative): the function will not be
> named `lookup`. The current leader in my eyes is Andreas Abel's
> `lookupEntry`, but I could be convinced to use something else if others
> prefer
> On Jun 29, 2016 5:12 PM, "Alec" <alec at deviant-logic.net> wrote:
>
>> > Are there many cases where we want `lookup` where we don't actually
>> want `intern`?
>>
>> Anecdotally, the majority of the times I've wanted `intern`
>> functionality, I've been implementing something full-text-search-like.
>> This meant having a "load the lexicon" phase, where a set of blessed words
>> get `intern`ed, and then a query phase where I want is `lookup` because my
>> lexicon is doing double duty as a stoplist.  I have no sense of whether
>> this would be a common case.
>>
>> Also, +1 for `intern`, +1 for `lookup`.  I'm fine with both names.
>>
>> On Wed, Jun 29, 2016 at 4:57 PM David Thomas <davidleothomas at gmail.com>
>> wrote:
>>
>>> Well, "intern" includes a "and if it is not there, add it".  Calling
>>> this "intern" without that behavior would be highly misleading.  That
>>> said, maybe we just want an "intern" function?  It would save us a dip
>>> into the set, for new strings and leave (marginally) less room to make
>>> a mistake.  Are there many cases where we want `lookup` where we don't
>>> actually want `intern`?
>>>
>>> On Tue, Jun 28, 2016 at 2:22 AM, Chris Wong <lambda.fairy at gmail.com>
>>> wrote:
>>> > Python uses "intern", so perhaps that can serve as the name.
>>> >
>>> > (See https://docs.python.org/2/library/functions.html#intern)
>>> >
>>> > On Tue, Jun 28, 2016 at 9:47 AM, David Feuer <david.feuer at gmail.com>
>>> wrote:
>>> >> +1 on the function. -1/2 on the name.
>>> >>
>>> >> On Jun 27, 2016 5:45 PM, "Nicolas Godbout" <nicolas.godbout at gmail.com
>>> >
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>> WHAT
>>> >>>
>>> >>> It is proposed to add a ‘lookup' function on 'Set' in the
>>> "containers"
>>> >>> package. Feedback during the next two weeks is welcome.
>>> >>>
>>> >>> 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 pull request at
>>> >>> https://github.com/haskell/containers/pull/291
>>> >>> contains the straight-forward implementation of the 'lookup’
>>> function on
>>> >>> 'Set', with test cases,
>>> >>> as a patch against the current containers master branch.
>>> >>>
>>> >>>
>>> >>> Salutations,
>>> >>> Nicolas.
>>> >>>
>>> >>> _______________________________________________
>>> >>> 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
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Chris Wong (https://lambda.xyz)
>>> >
>>> > "I had not the vaguest idea what this meant and when I could not
>>> > remember the words, my tutor threw the book at my head, which did not
>>> > stimulate my intellect in any way." -- Bertrand Russell
>>> > _______________________________________________
>>> > 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/20160629/708c18f9/attachment.html>