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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Godbout

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer

+1 on the function. -1/2 on the name.

On Jun 27, 2016 5:45 PM, "Nicolas Godbout" <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Godbout
David Feuer wrote:

+1 on the function. -1/2 on the name.


To be honest, I briefly considered the name `lookupEQ`. The name would fit nicely with `lookupGT` and company.

Nicolas.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer

As much as I dislike the names lookupGT, et al, I think that's probably your best bet now that they exist.

On Jun 27, 2016 5:52 PM, "Nicolas Godbout" <[hidden email]> wrote:
David Feuer wrote:

+1 on the function. -1/2 on the name.


To be honest, I briefly considered the name `lookupEQ`. The name would fit nicely with `lookupGT` and company.

Nicolas.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer

Another option might be "find".

On Jun 27, 2016 5:56 PM, "David Feuer" <[hidden email]> wrote:

As much as I dislike the names lookupGT, et al, I think that's probably your best bet now that they exist.

On Jun 27, 2016 5:52 PM, "Nicolas Godbout" <[hidden email]> wrote:
David Feuer wrote:

+1 on the function. -1/2 on the name.


To be honest, I briefly considered the name `lookupEQ`. The name would fit nicely with `lookupGT` and company.

Nicolas.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Malcolm Wallace-2
Or "lookupSharedPointer", if that is the important part of the operational semantics.

 Regards,
    Malcolm (iPhone)

On 27 Jun 2016, at 23:17, David Feuer <[hidden email]> wrote:

Another option might be "find".

On Jun 27, 2016 5:56 PM, "David Feuer" <[hidden email]> wrote:

As much as I dislike the names lookupGT, et al, I think that's probably your best bet now that they exist.

On Jun 27, 2016 5:52 PM, "Nicolas Godbout" <[hidden email]> wrote:
David Feuer wrote:

+1 on the function. -1/2 on the name.


To be honest, I briefly considered the name `lookupEQ`. The name would fit nicely with `lookupGT` and company.

Nicolas.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Joachim Breitner-2
Hi,

given that for naive uses and users, the existence of lookup is more
confusing than helpful, I’m in favor of a name that indicates “this is
advanced foo”, a suitable documentation, and moving it to the very end
of the module documentation, as it is not a function you’d expect for a
set implementation.

The name "Pointer", though, might be a bit too low-level. Maybe
"lookupWithSharing"?

Greetings,
Joachim

Am Dienstag, den 28.06.2016, 06:14 +0100 schrieb Malcolm Wallace:

> Or "lookupSharedPointer", if that is the important part of the
> operational semantics.
>
>  Regards,
>     Malcolm (iPhone)
>
> On 27 Jun 2016, at 23:17, David Feuer <[hidden email]> wrote:
>
> Another option might be "find".
> On Jun 27, 2016 5:56 PM, "David Feuer" <[hidden email]> wrote:
> > As much as I dislike the names lookupGT, et al, I think that's
> > probably your best bet now that they exist.
> > On Jun 27, 2016 5:52 PM, "Nicolas Godbout" <[hidden email]
> > om> wrote:
> > > David Feuer wrote:
> > > > +1 on the function. -1/2 on the name.
> > >
> > > To be honest, I briefly considered the name `lookupEQ`. The name
> > > would fit nicely with `lookupGT` and company.
> > >
> > > Nicolas.
> > >
--

Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Henning Thielemann
In reply to this post by Nicolas Godbout

On Mon, 27 Jun 2016, Nicolas Godbout wrote:

> 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.

I think I'd prefer the (Map String String) variant to an obscure Set
lookup function. I wonder whether you will later use the Map anyway, as
the compiler grows and you need to attach more data to tokens. In order to
make your intent clearer you might define

   newtype SharedToken = SharedToken String

and use (Map String SharedToken).
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Chris Wong-2
In reply to this post by David Feuer
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 <[hidden email]> wrote:

> +1 on the function. -1/2 on the name.
>
> On Jun 27, 2016 5:45 PM, "Nicolas Godbout" <[hidden email]>
> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Oliver Charles-3

I don't really see the problem with lookup. To me, that function always takes a container, an index into that container, and returns the value under than index or fails. It just so happens that sets are indexed by the very values the contain, but I don't find the signature confusing. Sure, I might not use it very often, but it's still clear enough to me what it's doing.

Ollie


On Tue, 28 Jun 2016, 10:23 a.m. Chris Wong, <[hidden email]> 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 <[hidden email]> wrote:
> +1 on the function. -1/2 on the name.
>
> On Jun 27, 2016 5:45 PM, "Nicolas Godbout" <[hidden email]>
> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Andreas Abel
+1 for "lookup".

On 28.06.2016 11:44, Oliver Charles wrote:

> I don't really see the problem with lookup. To me, that function always
> takes a container, an index into that container, and returns the value
> under than index or fails. It just so happens that sets are indexed by
> the very values the contain, but I don't find the signature confusing.
> Sure, I might not use it very often, but it's still clear enough to me
> what it's doing.
>
> Ollie
>
>
> On Tue, 28 Jun 2016, 10:23 a.m. Chris Wong, <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      > +1 on the function. -1/2 on the name.
>      >
>      > On Jun 27, 2016 5:45 PM, "Nicolas Godbout"
>     <[hidden email] <mailto:[hidden email]>>
>      > 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
>      >> [hidden email] <mailto:[hidden email]>
>      >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>      >
>      >
>      > _______________________________________________
>      > Libraries mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > 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
>     [hidden email] <mailto:[hidden email]>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>


--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Michael Snoyman
Likewise, I'm not in favor of name proliferation. To avoid confusion, I think it's sufficient to give a clear comments in the Haddocks explaining why one would wish to use this function.

On Tue, Jun 28, 2016 at 12:53 PM, Andreas Abel <[hidden email]> wrote:
+1 for "lookup".

On 28.06.2016 11:44, Oliver Charles wrote:
I don't really see the problem with lookup. To me, that function always
takes a container, an index into that container, and returns the value
under than index or fails. It just so happens that sets are indexed by
the very values the contain, but I don't find the signature confusing.
Sure, I might not use it very often, but it's still clear enough to me
what it's doing.

Ollie


On Tue, 28 Jun 2016, 10:23 a.m. Chris Wong, <[hidden email]
<mailto:[hidden email]>> 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 <[hidden email]
    <mailto:[hidden email]>> wrote:
     > +1 on the function. -1/2 on the name.
     >
     > On Jun 27, 2016 5:45 PM, "Nicolas Godbout"
    <[hidden email] <mailto:[hidden email]>>

     > 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
     >> [hidden email] <mailto:[hidden email]>
     >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
     >
     >
     > _______________________________________________
     > Libraries mailing list
     > [hidden email] <mailto:[hidden email]>
     > 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
    [hidden email] <mailto:[hidden email]>
    http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Bardur Arantsson-2
In reply to this post by Oliver Charles-3
On 06/28/2016 11:44 AM, Oliver Charles wrote:
> I don't really see the problem with lookup. To me, that function always
> takes a container, an index into that container, and returns the value
> under than index or fails. It just so happens that sets are indexed by
> the very values the contain, but I don't find the signature confusing.
> Sure, I might not use it very often, but it's still clear enough to me
> what it's doing.
>

+1


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Turner-2
In reply to this post by Nicolas Godbout

+1

When I previously searched for (and failed to find) this function in order to implement an intern table, I remember trying 'lookup', 'lookupEQ' and 'find' in approximately that order, so that's my order if preference for its name.

'lookupInterned' or similar could work for me too if you want to scare off beginners although I don't see a strong need myself. Certainly a mention of interning in the haddocks would help.


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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer
Would we also want something similar for `Data.Map`, looking up a key
and returning the copy of the key found in the map along with the
associated value?

lookupWithInternedKeyOrWhatever :: Ord k => k -> Map k v -> (k, v)

If so, it might pay to think about a naming scheme that will make
sense for both Data.Map and Data.Set.

On Tue, Jun 28, 2016 at 12:38 PM, David Turner
<[hidden email]> wrote:

> +1
>
> When I previously searched for (and failed to find) this function in order
> to implement an intern table, I remember trying 'lookup', 'lookupEQ' and
> 'find' in approximately that order, so that's my order if preference for its
> name.
>
> 'lookupInterned' or similar could work for me too if you want to scare off
> beginners although I don't see a strong need myself. Certainly a mention of
> interning in the haddocks would help.
>
>
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Joachim Breitner-2
Hi,

good point. How about

    lookupKey :: Ord a => a -> Set a -> Maybe a

and

    lookupKey :: Ord a => k -> Map k v -> Maybe (k, v)


It might be a bit strange to talk about key in the context of Sets, but
less so to someone who knows about sharing and pointers etc, and the
naming convention works well for maps. There, looking up the key is
likely the main purpose of the function; that we return the value along
with it is a nice bonus.

Greetings,
Joachim

Am Mittwoch, den 29.06.2016, 02:12 -0400 schrieb David Feuer:

> Would we also want something similar for `Data.Map`, looking up a key
> and returning the copy of the key found in the map along with the
> associated value?
>
> lookupWithInternedKeyOrWhatever :: Ord k => k -> Map k v -> (k, v)
>
> If so, it might pay to think about a naming scheme that will make
> sense for both Data.Map and Data.Set.
>
> On Tue, Jun 28, 2016 at 12:38 PM, David Turner
> <[hidden email]> wrote:
> > +1
> >
> > When I previously searched for (and failed to find) this function
> > in order
> > to implement an intern table, I remember trying 'lookup',
> > 'lookupEQ' and
> > 'find' in approximately that order, so that's my order if
> > preference for its
> > name.
> >
> > 'lookupInterned' or similar could work for me too if you want to
> > scare off
> > beginners although I don't see a strong need myself. Certainly a
> > mention of
> > interning in the haddocks would help.
> >
> >
> > 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> > _______________________________________________
> > Libraries mailing list
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--

Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
As another color for the bikeshed: lookupWithKey would match the existing vocabulary of insertWithKey, etc. 

We could further document the rest of them to include the assertion that the copy of the key they give back to the combinator is the one found in the Map/Set and not the one given. Then this is just the continuation of an existing pattern in the library.

-Edward

On Wed, Jun 29, 2016 at 4:18 AM, Joachim Breitner <[hidden email]> wrote:
Hi,

good point. How about

    lookupKey :: Ord a => a -> Set a -> Maybe a

and

    lookupKey :: Ord a => k -> Map k v -> Maybe (k, v)


It might be a bit strange to talk about key in the context of Sets, but
less so to someone who knows about sharing and pointers etc, and the
naming convention works well for maps. There, looking up the key is
likely the main purpose of the function; that we return the value along
with it is a nice bonus.

Greetings,
Joachim

Am Mittwoch, den 29.06.2016, 02:12 -0400 schrieb David Feuer:
> Would we also want something similar for `Data.Map`, looking up a key
> and returning the copy of the key found in the map along with the
> associated value?
>
> lookupWithInternedKeyOrWhatever :: Ord k => k -> Map k v -> (k, v)
>
> If so, it might pay to think about a naming scheme that will make
> sense for both Data.Map and Data.Set.
>
> On Tue, Jun 28, 2016 at 12:38 PM, David Turner
> <[hidden email]> wrote:
> > +1
> >
> > When I previously searched for (and failed to find) this function
> > in order
> > to implement an intern table, I remember trying 'lookup',
> > 'lookupEQ' and
> > 'find' in approximately that order, so that's my order if
> > preference for its
> > name.
> >
> > 'lookupInterned' or similar could work for me too if you want to
> > scare off
> > beginners although I don't see a strong need myself. Certainly a
> > mention of
> > interning in the haddocks would help.
> >
> >
> > 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> > _______________________________________________
> > Libraries mailing list
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--

Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Andreas Abel
On 29.06.2016 11:17, Edward Kmett wrote:
> As another color for the bikeshed: lookupWithKey would match the
> existing vocabulary of insertWithKey, etc.

Even though they have a different ethymology, coming from insertWith
(with a function) etc.!?

Another bikeshed

   lookupEntry :: Ord a => a -> Set a -> Maybe a
   lookupEntry :: Ord a => k -> Map k v -> Maybe (k, v)

since it retrieves the whole set/map entry and not just the value.

> We could further document the rest of them to include the assertion that
> the copy of the key they give back to the combinator is the one found in
> the Map/Set and not the one given. Then this is just the continuation of
> an existing pattern in the library.
>
> -Edward
>
> On Wed, Jun 29, 2016 at 4:18 AM, Joachim Breitner
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     good point. How about
>
>          lookupKey :: Ord a => a -> Set a -> Maybe a
>
>     and
>
>          lookupKey :: Ord a => k -> Map k v -> Maybe (k, v)
>
>
>     It might be a bit strange to talk about key in the context of Sets, but
>     less so to someone who knows about sharing and pointers etc, and the
>     naming convention works well for maps. There, looking up the key is
>     likely the main purpose of the function; that we return the value along
>     with it is a nice bonus.
>
>     Greetings,
>     Joachim
>
>     Am Mittwoch, den 29.06.2016, 02:12 -0400 schrieb David Feuer:
>      > Would we also want something similar for `Data.Map`, looking up a key
>      > and returning the copy of the key found in the map along with the
>      > associated value?
>      >
>      > lookupWithInternedKeyOrWhatever :: Ord k => k -> Map k v -> (k, v)
>      >
>      > If so, it might pay to think about a naming scheme that will make
>      > sense for both Data.Map and Data.Set.
>      >
>      > On Tue, Jun 28, 2016 at 12:38 PM, David Turner
>      > <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      > > +1
>      > >
>      > > When I previously searched for (and failed to find) this function
>      > > in order
>      > > to implement an intern table, I remember trying 'lookup',
>      > > 'lookupEQ' and
>      > > 'find' in approximately that order, so that's my order if
>      > > preference for its
>      > > name.
>      > >
>      > > 'lookupInterned' or similar could work for me too if you want to
>      > > scare off
>      > > beginners although I don't see a strong need myself. Certainly a
>      > > mention of
>      > > interning in the haddocks would help.
>      > >
>      > >
>      > > 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
>      > > [hidden email] <mailto:[hidden email]>
>      > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>      > >
>      > > _______________________________________________
>      > > Libraries mailing list
>      > > [hidden email] <mailto:[hidden email]>
>      > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>      > >
>      > _______________________________________________
>      > Libraries mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>     --
>
>     Joachim “nomeata” Breitner
>     [hidden email] <mailto:[hidden email]> •
>     https://www.joachim-breitner.de/
>        XMPP: [hidden email]
>     <mailto:[hidden email]> • OpenPGP-Key: 0xF0FBF51F
>        Debian Developer: [hidden email] <mailto:[hidden email]>
>
>     _______________________________________________
>     Libraries mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>


--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer
In reply to this post by Edward Kmett-2

I don't think all the other xxxWith functions currently make this guarantee! I think they should, though.

On Jun 29, 2016 5:17 AM, "Edward Kmett" <[hidden email]> wrote:
As another color for the bikeshed: lookupWithKey would match the existing vocabulary of insertWithKey, etc. 

We could further document the rest of them to include the assertion that the copy of the key they give back to the combinator is the one found in the Map/Set and not the one given. Then this is just the continuation of an existing pattern in the library.

-Edward

On Wed, Jun 29, 2016 at 4:18 AM, Joachim Breitner <[hidden email]> wrote:
Hi,

good point. How about

    lookupKey :: Ord a => a -> Set a -> Maybe a

and

    lookupKey :: Ord a => k -> Map k v -> Maybe (k, v)


It might be a bit strange to talk about key in the context of Sets, but
less so to someone who knows about sharing and pointers etc, and the
naming convention works well for maps. There, looking up the key is
likely the main purpose of the function; that we return the value along
with it is a nice bonus.

Greetings,
Joachim

Am Mittwoch, den 29.06.2016, 02:12 -0400 schrieb David Feuer:
> Would we also want something similar for `Data.Map`, looking up a key
> and returning the copy of the key found in the map along with the
> associated value?
>
> lookupWithInternedKeyOrWhatever :: Ord k => k -> Map k v -> (k, v)
>
> If so, it might pay to think about a naming scheme that will make
> sense for both Data.Map and Data.Set.
>
> On Tue, Jun 28, 2016 at 12:38 PM, David Turner
> <[hidden email]> wrote:
> > +1
> >
> > When I previously searched for (and failed to find) this function
> > in order
> > to implement an intern table, I remember trying 'lookup',
> > 'lookupEQ' and
> > 'find' in approximately that order, so that's my order if
> > preference for its
> > name.
> >
> > 'lookupInterned' or similar could work for me too if you want to
> > scare off
> > beginners although I don't see a strong need myself. Certainly a
> > mention of
> > interning in the haddocks would help.
> >
> >
> > 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> > _______________________________________________
> > Libraries mailing list
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--

Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer
In reply to this post by Andreas Abel
+1 for lookupEntry. I think that's very intuitive.

On Wed, Jun 29, 2016 at 8:36 AM, Andreas Abel <[hidden email]> wrote:

> On 29.06.2016 11:17, Edward Kmett wrote:
>>
>> As another color for the bikeshed: lookupWithKey would match the
>> existing vocabulary of insertWithKey, etc.
>
>
> Even though they have a different ethymology, coming from insertWith (with a
> function) etc.!?
>
> Another bikeshed
>
>   lookupEntry :: Ord a => a -> Set a -> Maybe a
>   lookupEntry :: Ord a => k -> Map k v -> Maybe (k, v)
>
> since it retrieves the whole set/map entry and not just the value.
>
>> We could further document the rest of them to include the assertion that
>> the copy of the key they give back to the combinator is the one found in
>> the Map/Set and not the one given. Then this is just the continuation of
>> an existing pattern in the library.
>>
>> -Edward
>>
>> On Wed, Jun 29, 2016 at 4:18 AM, Joachim Breitner
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     Hi,
>>
>>     good point. How about
>>
>>          lookupKey :: Ord a => a -> Set a -> Maybe a
>>
>>     and
>>
>>          lookupKey :: Ord a => k -> Map k v -> Maybe (k, v)
>>
>>
>>     It might be a bit strange to talk about key in the context of Sets,
>> but
>>     less so to someone who knows about sharing and pointers etc, and the
>>     naming convention works well for maps. There, looking up the key is
>>     likely the main purpose of the function; that we return the value
>> along
>>     with it is a nice bonus.
>>
>>     Greetings,
>>     Joachim
>>
>>     Am Mittwoch, den 29.06.2016, 02:12 -0400 schrieb David Feuer:
>>      > Would we also want something similar for `Data.Map`, looking up a
>> key
>>      > and returning the copy of the key found in the map along with the
>>      > associated value?
>>      >
>>      > lookupWithInternedKeyOrWhatever :: Ord k => k -> Map k v -> (k, v)
>>      >
>>      > If so, it might pay to think about a naming scheme that will make
>>      > sense for both Data.Map and Data.Set.
>>      >
>>      > On Tue, Jun 28, 2016 at 12:38 PM, David Turner
>>      > <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>      > > +1
>>      > >
>>      > > When I previously searched for (and failed to find) this function
>>      > > in order
>>      > > to implement an intern table, I remember trying 'lookup',
>>      > > 'lookupEQ' and
>>      > > 'find' in approximately that order, so that's my order if
>>      > > preference for its
>>      > > name.
>>      > >
>>      > > 'lookupInterned' or similar could work for me too if you want to
>>      > > scare off
>>      > > beginners although I don't see a strong need myself. Certainly a
>>      > > mention of
>>      > > interning in the haddocks would help.
>>      > >
>>      > >
>>      > > 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
>>      > > [hidden email] <mailto:[hidden email]>
>>      > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>      > >
>>      > > _______________________________________________
>>      > > Libraries mailing list
>>      > > [hidden email] <mailto:[hidden email]>
>>      > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>      > >
>>      > _______________________________________________
>>      > Libraries mailing list
>>      > [hidden email] <mailto:[hidden email]>
>>      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>     --
>>
>>     Joachim “nomeata” Breitner
>>     [hidden email] <mailto:[hidden email]> •
>>     https://www.joachim-breitner.de/
>>        XMPP: [hidden email]
>>     <mailto:[hidden email]> • OpenPGP-Key: 0xF0FBF51F
>>        Debian Developer: [hidden email] <mailto:[hidden email]>
>>
>>     _______________________________________________
>>     Libraries mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> [hidden email]
> http://www2.tcs.ifi.lmu.de/~abel/
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
12