<p dir="ltr">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 </p>
<div class="gmail_quote">On Jun 29, 2016 5:12 PM, "Alec" <<a href="mailto:alec@deviant-logic.net">alec@deviant-logic.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">> Are there many cases where we want `lookup` where we don't </span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">actually want `intern`?</span><br><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><br></span></div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">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.</span></div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><br></span></div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">Also, +1 for `intern`, +1 for `lookup`.  I'm fine with both names.</span></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 29, 2016 at 4:57 PM David Thomas <<a href="mailto:davidleothomas@gmail.com" target="_blank">davidleothomas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, "intern" includes a "and if it is not there, add it".  Calling<br>
this "intern" without that behavior would be highly misleading.  That<br>
said, maybe we just want an "intern" function?  It would save us a dip<br>
into the set, for new strings and leave (marginally) less room to make<br>
a mistake.  Are there many cases where we want `lookup` where we don't<br>
actually want `intern`?<br>
<br>
On Tue, Jun 28, 2016 at 2:22 AM, Chris Wong <<a href="mailto:lambda.fairy@gmail.com" target="_blank">lambda.fairy@gmail.com</a>> wrote:<br>
> Python uses "intern", so perhaps that can serve as the name.<br>
><br>
> (See <a href="https://docs.python.org/2/library/functions.html#intern" rel="noreferrer" target="_blank">https://docs.python.org/2/library/functions.html#intern</a>)<br>
><br>
> On Tue, Jun 28, 2016 at 9:47 AM, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
>> +1 on the function. -1/2 on the name.<br>
>><br>
>> On Jun 27, 2016 5:45 PM, "Nicolas Godbout" <<a href="mailto:nicolas.godbout@gmail.com" target="_blank">nicolas.godbout@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>> WHAT<br>
>>><br>
>>> It is proposed to add a ‘lookup' function on 'Set' in the "containers"<br>
>>> package. Feedback during the next two weeks is welcome.<br>
>>><br>
>>> The function<br>
>>><br>
>>> > lookup :: Ord a => a -> Set a -> Maybe a<br>
>>><br>
>>> is almost indentical to the 'member' function but, in addition, returns<br>
>>> the value<br>
>>> stored in the set.<br>
>>><br>
>>> WHY<br>
>>><br>
>>> The point of this proposal is to facilitate program-wide data sharing. The<br>
>>> 'lookup'<br>
>>> function gives access to a pointer to an object already stored in a Set<br>
>>> and equal<br>
>>> to a given argument. The 'lookup' function is a natural extension to the<br>
>>> current<br>
>>> 'lookupLT', 'lookupGT', 'lookupLE' and 'lookupGE' functions, with obvious<br>
>>> semantics.<br>
>>><br>
>>> Example use case: In a parser, the memory footprint can be reduced by<br>
>>> collapsing<br>
>>> all equal strings to a single instance of each string. To achieve this,<br>
>>> one needs<br>
>>> a way to get a previously seen string (internally, a pointer) equal to a<br>
>>> newly<br>
>>> parsed string. Amazingly, this is very difficult with the current<br>
>>> "containers" library interface.<br>
>>> One current option is to use a Map instead, e.g., 'Map String String'<br>
>>> which stores twice as many pointers as necessary.<br>
>>><br>
>>> HOW<br>
>>><br>
>>> The git pull request at<br>
>>> <a href="https://github.com/haskell/containers/pull/291" rel="noreferrer" target="_blank">https://github.com/haskell/containers/pull/291</a><br>
>>> contains the straight-forward implementation of the 'lookup’ function on<br>
>>> 'Set', with test cases,<br>
>>> as a patch against the current containers master branch.<br>
>>><br>
>>><br>
>>> Salutations,<br>
>>> Nicolas.<br>
>>><br>
>>> _______________________________________________<br>
>>> Libraries mailing list<br>
>>> <a href="mailto:Libraries@haskell.org" target="_blank">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>
>><br>
>><br>
>> _______________________________________________<br>
>> Libraries mailing list<br>
>> <a href="mailto:Libraries@haskell.org" target="_blank">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>
>><br>
><br>
><br>
><br>
> --<br>
> Chris Wong (<a href="https://lambda.xyz" rel="noreferrer" target="_blank">https://lambda.xyz</a>)<br>
><br>
> "I had not the vaguest idea what this meant and when I could not<br>
> remember the words, my tutor threw the book at my head, which did not<br>
> stimulate my intellect in any way." -- Bertrand Russell<br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">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>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">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>
<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>
<br></blockquote></div>