From holmisen at gmail.com  Wed Jun  1 07:36:32 2016
From: holmisen at gmail.com (Johan Holmquist)
Date: Wed, 1 Jun 2016 09:36:32 +0200
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <CABUjdS4GACtbUitJ_zkxGGAAGF-xKY-QetQiaUMT3FbWq1ZRMQ@mail.gmail.com>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
 <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
 <CAB_cSPcYfrbvPS6EVo72twfVDuKV39JA-eARX3r=ZV1SRW7vbA@mail.gmail.com>
 <CAJoPsuDAq1aqiJ6th6pMNv+872RnYwb97zWCu5KWvMJzz8-5xA@mail.gmail.com>
 <CABUjdS4GACtbUitJ_zkxGGAAGF-xKY-QetQiaUMT3FbWq1ZRMQ@mail.gmail.com>
Message-ID: <CAB_cSPf7wvNp4yfb5d_FB7xEiKyhjgMRrDSOmjavnq=RHB4_rQ@mail.gmail.com>

We have now passed the deadline for discussion of this proposal.

The count is 2 for and 3 against. Including myself in the vote would yield
a tie on the outcome.

The response was more positive than I had thought it would be, albeit not
entirely conclusive. I think it would be fair to put this to rest for now.
I guess it will come up again in the future, since the functions are useful
enough to warrant a common name IMO.

Many thanks to all for the valuable input.

/Johan


2016-05-20 7:27 GMT+02:00 wren romano <winterkoninkje at gmail.com>:

> On Thu, May 19, 2016 at 2:33 PM, Theodore Lief Gannon <tanuki at gmail.com>
> wrote:
> > Whoops, responded privately (and also made a mistake I wanted to
> correct, so
> > I guess that works out). To the list this time:
> >
> > I don't like using the 'zip' terminology here; I feel like that should be
> > reserved for multiple distinct data sources.
> >
> > Why not 'map2'?
>
> I too dislike the "zip" terminology here, for the same reason. But I
> also I mislike "map" since this isn't functorial in any particular way
> (I'd expect "map2" to have to do with some sort of 2-functors).
>
> I'm agnostic on adding the function vs not, but If we're bikeshedding
> for short names how about "twine"? (The problem I see with "pairwise"
> is that it's ambiguous about whether values get "reused": i.e.,
> matching even elements to odds[1], vs matching every element to the
> next/last.)
>
> [1] I also note without comment that this interpretation is the
> inverse to what is traditionally called "zip" in the non-wellfounded
> set theory community; e.g., when viewing streams (like the Thue?Morse
> sequence) as a greatest solution to a system of equations.
>
> --
> Live well,
> ~wren
> _______________________________________________
> 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/20160601/d10c960e/attachment.html>

From anfelor at posteo.de  Fri Jun  3 15:49:02 2016
From: anfelor at posteo.de (Anton Felix Lorenzen)
Date: Fri, 3 Jun 2016 17:49:02 +0200
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
Message-ID: <a496fc80-d39b-830b-dea0-16da35fdb569@posteo.de>

It has been two weeks now since I wrote my proposal.

First of all, thanks to all for their replies
(and sorry for having started such a big discussion).

Tom has mentioned, that there is (\(Right x)->x).
I didn't consider that (shame on me), but I think it is perfect
as it is short and easy to read.

Also it shows the idea of unwrapping,
something which "either undefined id" lacks.

I think it is a good replacement
and therefore withdraw my proposal.


Meanwhile, it was proposed to include
   fromLeft  :: a -> Either a b -> a
   fromRight :: b -> Either a b -> b
I am a weak +1 on this.

--
Anton

On 05/20/2016 10:08 PM, Anton Felix Lorenzen wrote:
> When working with Either,
> I am often missing two simple functions:
> fromRight :: Either a b -> b
> fromLeft  :: Either a b -> a
>
> It has been implemented a couple of times:
> http://hayoo.fh-wedel.de/?query=fromRight
>
> But I don't want to depend on yet another library
> for such a basic function.
>
> Could it be added?
>
> Anton
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From hvriedel at gmail.com  Mon Jun  6 11:30:10 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Mon, 06 Jun 2016 13:30:10 +0200
Subject: Proposal: Left-Associative Semigroup Operator Alias in
 "Data.Semigroup"
Message-ID: <87d1nupnb1.fsf@gnu.org>

Hello!

In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>)
subtly conflicts with definitions of (<>) in pretty printing APIs, for
which the left-associative variant is sometimes desirable. This subtle
overloading of (<>) is error-prone, as one has to remember which version
of (<>) is currently in scope in order to be able to reason about
non-trivial expressions involving this operator.

This proposal is an attempt to resolve this unfortunate and confusing
situation by completing the `Semigroup`/`Monoid` vocabulary with a
standard left-associative alias. Please see

  https://ghc.haskell.org/trac/ghc/wiki/Proposal/LeftAssocSemigroupOp

for more details.

Discussion period: 4 weeks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160606/d46ec0e2/attachment.sig>

From mblazevic at stilo.com  Mon Jun  6 13:45:25 2016
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Mon, 6 Jun 2016 09:45:25 -0400
Subject: Proposal: Left-Associative Semigroup Operator Alias in
 "Data.Semigroup"
In-Reply-To: <87d1nupnb1.fsf@gnu.org>
References: <87d1nupnb1.fsf@gnu.org>
Message-ID: <57557E75.7050006@stilo.com>

On 2016-06-06 07:30 AM, Herbert Valerio Riedel wrote:
> Hello!
>
> In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>)
> subtly conflicts with definitions of (<>) in pretty printing APIs, for
> which the left-associative variant is sometimes desirable. This subtle
> overloading of (<>) is error-prone, as one has to remember which version
> of (<>) is currently in scope in order to be able to reason about
> non-trivial expressions involving this operator.
>
> This proposal is an attempt to resolve this unfortunate and confusing
> situation by completing the `Semigroup`/`Monoid` vocabulary with a
> standard left-associative alias. Please see
>
>    https://ghc.haskell.org/trac/ghc/wiki/Proposal/LeftAssocSemigroupOp
>
> for more details.
>
> Discussion period: 4 weeks
>
>

	The proposal is well argued, but it omits any discussion of the proper 
place for the new operator. Why place it in Data.Semigroup, if its only 
purpose is to support the pretty-print libraries? Since the libraries in 
question will need to change anyway, or at least their imports will, why 
not add the operator there instead? Or, alternatively, to a 
Text.PrettyPrint module?


From tikhon at jelv.is  Mon Jun  6 21:25:27 2016
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Mon, 6 Jun 2016 14:25:27 -0700
Subject: Proposal: Left-Associative Semigroup Operator Alias in
 "Data.Semigroup"
In-Reply-To: <57557E75.7050006@stilo.com>
References: <87d1nupnb1.fsf@gnu.org>
	<57557E75.7050006@stilo.com>
Message-ID: <CAJN5CVJdCQnW-Dqc_kpkmf-q+vAUNXCwNrc2JOyRfw2rTNyM7Q@mail.gmail.com>

Are there other use cases where the left-associative operator enables nicer
code? I suspect that they are, but I can't think of any myself.

On Mon, Jun 6, 2016 at 6:45 AM, Mario Bla?evi? <mblazevic at stilo.com> wrote:

> On 2016-06-06 07:30 AM, Herbert Valerio Riedel wrote:
>
>> Hello!
>>
>> In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>)
>> subtly conflicts with definitions of (<>) in pretty printing APIs, for
>> which the left-associative variant is sometimes desirable. This subtle
>> overloading of (<>) is error-prone, as one has to remember which version
>> of (<>) is currently in scope in order to be able to reason about
>> non-trivial expressions involving this operator.
>>
>> This proposal is an attempt to resolve this unfortunate and confusing
>> situation by completing the `Semigroup`/`Monoid` vocabulary with a
>> standard left-associative alias. Please see
>>
>>    https://ghc.haskell.org/trac/ghc/wiki/Proposal/LeftAssocSemigroupOp
>>
>> for more details.
>>
>> Discussion period: 4 weeks
>>
>>
>>
>         The proposal is well argued, but it omits any discussion of the
> proper place for the new operator. Why place it in Data.Semigroup, if its
> only purpose is to support the pretty-print libraries? Since the libraries
> in question will need to change anyway, or at least their imports will, why
> not add the operator there instead? Or, alternatively, to a
> Text.PrettyPrint module?
>
> _______________________________________________
> 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/20160606/c55b8f6c/attachment.html>

From mail at joachim-breitner.de  Tue Jun  7 08:32:56 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 07 Jun 2016 10:32:56 +0200
Subject: Proposal: Left-Associative Semigroup Operator Alias in
 "Data.Semigroup"
In-Reply-To: <87d1nupnb1.fsf@gnu.org>
References: <87d1nupnb1.fsf@gnu.org>
Message-ID: <1465288376.1718.23.camel@joachim-breitner.de>

Hi,

Am Montag, den 06.06.2016, 13:30 +0200 schrieb Herbert Valerio Riedel:
> This proposal is an attempt to resolve this unfortunate and confusing
> situation by completing the `Semigroup`/`Monoid` vocabulary with a
> standard left-associative alias. Please see
> 
> ? https://ghc.haskell.org/trac/ghc/wiki/Proposal/LeftAssocSemigroupOp
> 
> for more details.

I?m have a few qualms.

?* There is no precedent for offering the same operator with different?
? ?fixities. Is this not totally confusing to many users? Will they
? ?confuse syntactic fixity with the efficient way? I am fearing
? ?thoughts like ?A, I should not use (++) to append lists to long
? ?lists, but luckily there is >< which has the right fixity??

?* Is it worth using up yet another operator name in a commonly?
? ?imported module?
? ?With nice things like <*>, <$> and <> taken, I sometimes have
? ?a hard time giving names to my own operators.

It could be put in a usually-not-imported module
(Data.Monoid.LeftAssociative) and re-exported by affected APIs (pretty-
printing libraries), with a proper explanation in their haddock. This
way, both qualms are mitigated and contained.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160607/e75a6e28/attachment.sig>

From bergey at alum.mit.edu  Tue Jun  7 13:24:45 2016
From: bergey at alum.mit.edu (Daniel Bergey)
Date: Tue, 07 Jun 2016 09:24:45 -0400
Subject: Proposal: Left-Associative Semigroup Operator Alias in
 "Data.Semigroup"
In-Reply-To: <87d1nupnb1.fsf@gnu.org>
References: <87d1nupnb1.fsf@gnu.org>
Message-ID: <87twh5b082.fsf@chladni.i-did-not-set--mail-host-address--so-tickle-me>

I sent this from the wrong address, and am resending.  Appologies to
those on both mailing lists, who will get two copies.

I've often needed to use Semigroup <> and pretty-print <> in the same
module.  Thanks for trying to improve the situation.

Are there other Semigroups where people want the right-associative ><?
I'm trying to understand the proposal to put this in Data.Semigroup
rather than in `pretty`

A discussion[1] linked from the wiki suggests that the left-associative
version *may* have better asymptotics.  Is this confirmed?

Is this change mostly motivated by in-GHC use of `pretty`?

Is there a reason expressions like `a <> b <+> c` occur more often than
`a <+> b <> c`?  Or is that just an artifact of the pretty-printing <>
being left-associative?

If I understand the proposed migration path, upgrading `pretty` without
changing my code would silently change semantics.  Upgrading correctly
requires s/<>/></ which is easy, but requires dropping support for old
base / pretty, or CPP to define >< locally.  This leaves me with a funny
(><) operator that seems mostly historical, and still the surprising
behavior of `a <+> b >< c`.

This doesn't seem like an attractive migration for anywhere I use
pretty-printing.  Maybe it's still the best answer for GHC internal use;
I can't tell.

cheers,
bergey

Footnotes: 
[1]  https://github.com/haskell/pretty/issues/30#issuecomment-161146748

On 2016-06-06 at 07:30, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> Hello!
>
> In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>)
> subtly conflicts with definitions of (<>) in pretty printing APIs, for
> which the left-associative variant is sometimes desirable. This subtle
> overloading of (<>) is error-prone, as one has to remember which version
> of (<>) is currently in scope in order to be able to reason about
> non-trivial expressions involving this operator.
>
> This proposal is an attempt to resolve this unfortunate and confusing
> situation by completing the `Semigroup`/`Monoid` vocabulary with a
> standard left-associative alias. Please see
>
>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/LeftAssocSemigroupOp
>
> for more details.
>
> Discussion period: 4 weeks
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ivan.miljenovic at gmail.com  Tue Jun  7 14:12:11 2016
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Wed, 8 Jun 2016 00:12:11 +1000
Subject: Proposal: Left-Associative Semigroup Operator Alias in
 "Data.Semigroup"
In-Reply-To: <87twh5b082.fsf@chladni.i-did-not-set--mail-host-address--so-tickle-me>
References: <87d1nupnb1.fsf@gnu.org>
 <87twh5b082.fsf@chladni.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <CA+u6gbw8GqF9ohoWrwmMNJKvQoBOAX7yVb58RxCUCHU8Zi8wAQ@mail.gmail.com>

On 7 June 2016 at 23:24, Daniel Bergey <bergey at alum.mit.edu> wrote:
> I sent this from the wrong address, and am resending.  Appologies to
> those on both mailing lists, who will get two copies.
>
> I've often needed to use Semigroup <> and pretty-print <> in the same
> module.  Thanks for trying to improve the situation.
>
> Are there other Semigroups where people want the right-associative ><?
> I'm trying to understand the proposal to put this in Data.Semigroup
> rather than in `pretty`

I think one argument is that if it's in `pretty` it's in a single
pretty-printing package; if it's in `base` somewhere then it's
available for use with all pretty-printing packages.

Note: I maintain wl-pprint-text, but in there I use the Data.Monoid
version of <>.  I admittedly haven't done any benchmarks to determine
whether this is an issue or not.

>
> A discussion[1] linked from the wiki suggests that the left-associative
> version *may* have better asymptotics.  Is this confirmed?
>
> Is this change mostly motivated by in-GHC use of `pretty`?
>
> Is there a reason expressions like `a <> b <+> c` occur more often than
> `a <+> b <> c`?  Or is that just an artifact of the pretty-printing <>
> being left-associative?
>
> If I understand the proposed migration path, upgrading `pretty` without
> changing my code would silently change semantics.  Upgrading correctly
> requires s/<>/></ which is easy, but requires dropping support for old
> base / pretty, or CPP to define >< locally.  This leaves me with a funny
> (><) operator that seems mostly historical, and still the surprising
> behavior of `a <+> b >< c`.
>
> This doesn't seem like an attractive migration for anywhere I use
> pretty-printing.  Maybe it's still the best answer for GHC internal use;
> I can't tell.
>
> cheers,
> bergey
>
> Footnotes:
> [1]  https://github.com/haskell/pretty/issues/30#issuecomment-161146748
>
> On 2016-06-06 at 07:30, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
>> Hello!
>>
>> In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>)
>> subtly conflicts with definitions of (<>) in pretty printing APIs, for
>> which the left-associative variant is sometimes desirable. This subtle
>> overloading of (<>) is error-prone, as one has to remember which version
>> of (<>) is currently in scope in order to be able to reason about
>> non-trivial expressions involving this operator.
>>
>> This proposal is an attempt to resolve this unfortunate and confusing
>> situation by completing the `Semigroup`/`Monoid` vocabulary with a
>> standard left-associative alias. Please see
>>
>>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/LeftAssocSemigroupOp
>>
>> for more details.
>>
>> Discussion period: 4 weeks
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From lemming at henning-thielemann.de  Wed Jun  8 08:10:17 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 8 Jun 2016 10:10:17 +0200 (CEST)
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <CAB_cSPf7wvNp4yfb5d_FB7xEiKyhjgMRrDSOmjavnq=RHB4_rQ@mail.gmail.com>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
 <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
 <CAB_cSPcYfrbvPS6EVo72twfVDuKV39JA-eARX3r=ZV1SRW7vbA@mail.gmail.com>
 <CAJoPsuDAq1aqiJ6th6pMNv+872RnYwb97zWCu5KWvMJzz8-5xA@mail.gmail.com>
 <CABUjdS4GACtbUitJ_zkxGGAAGF-xKY-QetQiaUMT3FbWq1ZRMQ@mail.gmail.com>
 <CAB_cSPf7wvNp4yfb5d_FB7xEiKyhjgMRrDSOmjavnq=RHB4_rQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1606081009340.9899@sputnik>


On Wed, 1 Jun 2016, Johan Holmquist wrote:

> The response was more positive than I had thought it would be, albeit not entirely conclusive. I think it would be fair
> to put this to rest for now. I guess it will come up again in the future, since the functions are useful enough to
> warrant a common name IMO.

In the meantime you can just use utility-ht:mapAdjacent. :-)

From david.feuer at gmail.com  Fri Jun 10 12:29:47 2016
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 10 Jun 2016 08:29:47 -0400
Subject: foldl' semantic change
In-Reply-To: <CAMgWh9vNbO8N-fj-W9QNLCxRtW9c3fUQxv4FeYc1LNEwgnuZsw@mail.gmail.com>
References: <CAMgWh9tpYm+O3C9F7OOk7OtZb-cNHCfW9BRvkYw35_u_9xnbvQ@mail.gmail.com>
 <CAMgWh9vxHKj3DyKfqjgAR+sdY=1qkutNsStvp1tsav11=E7g8g@mail.gmail.com>
 <CAMgWh9thupLpJYvbY=9JBMnS5Rjuq-FKUBSjNDP_snMGzXS7ew@mail.gmail.com>
 <CAMgWh9u2CuUwrLRAs8h5bqEqOq_L8MeNV-TufXUTM2-q8biroQ@mail.gmail.com>
 <CAMgWh9t-Dp206H83UVdO9dsG8ayByQinjX-2k0RO7yLTNq4m7A@mail.gmail.com>
 <CAMgWh9s4HJXZdrZ8b5DGcR3aepHtKCG6VFL43qAVgiePHoYdkQ@mail.gmail.com>
 <CAMgWh9vAG-LeaFKP10RYBOXtKPuGGXqRccRzS1BFhEtSby7JpA@mail.gmail.com>
 <CAMgWh9tybAzy8t9VquGTpDHpRGr4wce+ZvOtmv=rVZrpg9Rh8g@mail.gmail.com>
 <CAMgWh9u0htNNKbskRzZq8sKJ62TkM+bPK2itpJL0Tsf0TMLCsg@mail.gmail.com>
 <CAMgWh9uqmZ8whervOmUTf-q3xHNGe-CGYquse2P+Wo7E5ur3LQ@mail.gmail.com>
 <CAMgWh9veHP3yq5rA1AOwZXjkZML3WrnuAKa8-xehP0Ujq7Y8aw@mail.gmail.com>
 <CAMgWh9v6i4dX_Zj7ub4Y-GeXFw4Hcy6BYuyArtt_u7bAaAdwVA@mail.gmail.com>
 <CAMgWh9txtet0ata=Gq3XcniY5jrio_p=2Y7+iiyn4NUKQA-cOQ@mail.gmail.com>
 <CAMgWh9vNbO8N-fj-W9QNLCxRtW9c3fUQxv4FeYc1LNEwgnuZsw@mail.gmail.com>
Message-ID: <CAMgWh9taqMe-_1FDsd0OF25Q20h6ZgSg3mkfRq_y5X4P3D2Vsg@mail.gmail.com>

The semantics of foldl' for lists were changed between base 4.7 and base
4.8. Specifically, foldl' became strict in the initial value of its
accumulator. I opened http://ghc.haskell.org/trac/ghc/ticket/12173 to
report this. The change was entirely accidental, according to Joachim
Breitner. However, Duncan Coutts indicated he is pleased with the change. I
don't personally have a dog in this race, but I feel very strongly about
three things:

1. The strictness should be fully documented, both in Haddock and the next
Haskell Report (the Haskell 2010 Report does not go into sufficient detail
to support either choice).

2. There should be *one* meaning of foldl' in base. Thus the default
Foldable instance should match the ones for lists and arrays.

3. The containers package should be consistent with base in this regard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160610/55f610f8/attachment.html>

From bart.massey at gmail.com  Fri Jun 10 16:10:06 2016
From: bart.massey at gmail.com (Bart Massey)
Date: Fri, 10 Jun 2016 16:10:06 +0000
Subject: foldl' semantic change
In-Reply-To: <CAMgWh9taqMe-_1FDsd0OF25Q20h6ZgSg3mkfRq_y5X4P3D2Vsg@mail.gmail.com>
References: <CAMgWh9tpYm+O3C9F7OOk7OtZb-cNHCfW9BRvkYw35_u_9xnbvQ@mail.gmail.com>
 <CAMgWh9vxHKj3DyKfqjgAR+sdY=1qkutNsStvp1tsav11=E7g8g@mail.gmail.com>
 <CAMgWh9thupLpJYvbY=9JBMnS5Rjuq-FKUBSjNDP_snMGzXS7ew@mail.gmail.com>
 <CAMgWh9u2CuUwrLRAs8h5bqEqOq_L8MeNV-TufXUTM2-q8biroQ@mail.gmail.com>
 <CAMgWh9t-Dp206H83UVdO9dsG8ayByQinjX-2k0RO7yLTNq4m7A@mail.gmail.com>
 <CAMgWh9s4HJXZdrZ8b5DGcR3aepHtKCG6VFL43qAVgiePHoYdkQ@mail.gmail.com>
 <CAMgWh9vAG-LeaFKP10RYBOXtKPuGGXqRccRzS1BFhEtSby7JpA@mail.gmail.com>
 <CAMgWh9tybAzy8t9VquGTpDHpRGr4wce+ZvOtmv=rVZrpg9Rh8g@mail.gmail.com>
 <CAMgWh9u0htNNKbskRzZq8sKJ62TkM+bPK2itpJL0Tsf0TMLCsg@mail.gmail.com>
 <CAMgWh9uqmZ8whervOmUTf-q3xHNGe-CGYquse2P+Wo7E5ur3LQ@mail.gmail.com>
 <CAMgWh9veHP3yq5rA1AOwZXjkZML3WrnuAKa8-xehP0Ujq7Y8aw@mail.gmail.com>
 <CAMgWh9v6i4dX_Zj7ub4Y-GeXFw4Hcy6BYuyArtt_u7bAaAdwVA@mail.gmail.com>
 <CAMgWh9txtet0ata=Gq3XcniY5jrio_p=2Y7+iiyn4NUKQA-cOQ@mail.gmail.com>
 <CAMgWh9vNbO8N-fj-W9QNLCxRtW9c3fUQxv4FeYc1LNEwgnuZsw@mail.gmail.com>
 <CAMgWh9taqMe-_1FDsd0OF25Q20h6ZgSg3mkfRq_y5X4P3D2Vsg@mail.gmail.com>
Message-ID: <CAA6gtpn1y7G0zskdqrVy9wMP+fNQSRxH1bfcbSvRJDsCpu1c8A@mail.gmail.com>

-1 on retaining this. Part of the implied contract of Data.List is that all
functions be as lazy as possible. Besides, a change that potentially breaks
old programs that use foldl' seems like a bad idea unless there's a really
strong reason for it. I don't have an existing example offhand, but it
seems at least possible that something like

    last = foldl' (flip const) undefined

is out there...

On Fri, Jun 10, 2016 at 5:29 AM David Feuer <david.feuer at gmail.com> wrote:

> The semantics of foldl' for lists were changed between base 4.7 and base
> 4.8. Specifically, foldl' became strict in the initial value of its
> accumulator. I opened http://ghc.haskell.org/trac/ghc/ticket/12173 to
> report this. The change was entirely accidental, according to Joachim
> Breitner. However, Duncan Coutts indicated he is pleased with the change. I
> don't personally have a dog in this race, but I feel very strongly about
> three things:
>
> 1. The strictness should be fully documented, both in Haddock and the next
> Haskell Report (the Haskell 2010 Report does not go into sufficient detail
> to support either choice).
>
> 2. There should be *one* meaning of foldl' in base. Thus the default
> Foldable instance should match the ones for lists and arrays.
>
> 3. The containers package should be consistent with base in this regard.
> _______________________________________________
> 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/20160610/de932ada/attachment.html>

From alan.isaac at gmail.com  Fri Jun 10 16:30:49 2016
From: alan.isaac at gmail.com (Alan Isaac)
Date: Fri, 10 Jun 2016 12:30:49 -0400
Subject: Request: Add sortOn to Data.Sequence
In-Reply-To: <67ce4f89-9096-04ee-a8b1-e8cdb0b73633@gmail.com>
References: <67ce4f89-9096-04ee-a8b1-e8cdb0b73633@gmail.com>
Message-ID: <abbacffb-23b5-2268-df5e-1ab8fb5bc732@gmail.com>

REQUEST
-------

The request is to add `sortOn` to Data.Sequence.
`sortOn f` would be equivalent to `sortBy . comparing f`,
but would offer a performance advantage by using a Schwartzian
transform to only evaluate `f` once for each element
in the input sequence.


BACKGROUND
----------

Adding `sortOn` to `Data.List` was proposed at least as early as 2008:
http://www.haskell.org/pipermail/libraries/2008-October/010797.html
It was added in 2014, in response to this feature request:
https://ghc.haskell.org/trac/ghc/ticket/9004


RATIONALES
----------

- convenience
- performance: faster than `sortBy`
- safety: encourages (although does not require) reliance on existing instances of Ord
- interface consistency (specifically, when comparing to Data.List)

Comment: it is certainly possible to pick at each of these rationales.
See the discussion here:
http://stackoverflow.com/questions/37691898/why-is-sortby-so-oddly-unconstrained-and-why-no-general-sorton/37735121


SCOPE
-----

Introduces no new dependencies except possibly on `Data.Ord.comparing`.


SOLUTIONS
-----------

The implementation in Data.List is::

         sortOn :: Ord b => (a -> b) -> [a] -> [a]
         sortOn f = map snd . sortBy (comparing fst)
                            . map (\x -> let y = f x in y `seq` (y, x))

An analogous implementation is possible for Data.Sequence.
However, this request does not propose a specific implementation.


WHAT MIGHT BREAK
----------------

No anticipated breakage.


From david.feuer at gmail.com  Fri Jun 10 16:35:57 2016
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 10 Jun 2016 12:35:57 -0400
Subject: foldl' semantic change
In-Reply-To: <CAA6gtpn1y7G0zskdqrVy9wMP+fNQSRxH1bfcbSvRJDsCpu1c8A@mail.gmail.com>
References: <CAMgWh9tpYm+O3C9F7OOk7OtZb-cNHCfW9BRvkYw35_u_9xnbvQ@mail.gmail.com>
 <CAMgWh9vxHKj3DyKfqjgAR+sdY=1qkutNsStvp1tsav11=E7g8g@mail.gmail.com>
 <CAMgWh9thupLpJYvbY=9JBMnS5Rjuq-FKUBSjNDP_snMGzXS7ew@mail.gmail.com>
 <CAMgWh9u2CuUwrLRAs8h5bqEqOq_L8MeNV-TufXUTM2-q8biroQ@mail.gmail.com>
 <CAMgWh9t-Dp206H83UVdO9dsG8ayByQinjX-2k0RO7yLTNq4m7A@mail.gmail.com>
 <CAMgWh9s4HJXZdrZ8b5DGcR3aepHtKCG6VFL43qAVgiePHoYdkQ@mail.gmail.com>
 <CAMgWh9vAG-LeaFKP10RYBOXtKPuGGXqRccRzS1BFhEtSby7JpA@mail.gmail.com>
 <CAMgWh9tybAzy8t9VquGTpDHpRGr4wce+ZvOtmv=rVZrpg9Rh8g@mail.gmail.com>
 <CAMgWh9u0htNNKbskRzZq8sKJ62TkM+bPK2itpJL0Tsf0TMLCsg@mail.gmail.com>
 <CAMgWh9uqmZ8whervOmUTf-q3xHNGe-CGYquse2P+Wo7E5ur3LQ@mail.gmail.com>
 <CAMgWh9veHP3yq5rA1AOwZXjkZML3WrnuAKa8-xehP0Ujq7Y8aw@mail.gmail.com>
 <CAMgWh9v6i4dX_Zj7ub4Y-GeXFw4Hcy6BYuyArtt_u7bAaAdwVA@mail.gmail.com>
 <CAMgWh9txtet0ata=Gq3XcniY5jrio_p=2Y7+iiyn4NUKQA-cOQ@mail.gmail.com>
 <CAMgWh9vNbO8N-fj-W9QNLCxRtW9c3fUQxv4FeYc1LNEwgnuZsw@mail.gmail.com>
 <CAMgWh9taqMe-_1FDsd0OF25Q20h6ZgSg3mkfRq_y5X4P3D2Vsg@mail.gmail.com>
 <CAA6gtpn1y7G0zskdqrVy9wMP+fNQSRxH1bfcbSvRJDsCpu1c8A@mail.gmail.com>
Message-ID: <CAMgWh9v_rbpFGy5x0U-uaVnL0BaamKRySyrmi_-qqbd_CY2+Bw@mail.gmail.com>

I would certainly have agreed back when 4.8 was in development. This was
undoubtedly a breaking change. The fact that it's now been out for some
time muddies the waters. So does the fact that the strictness has never
been documented. It seems likely that most packages relying on the old
behavior have been updated, and it's possible that some may have come to
rely on it. I see this unfortunate situation as something of an opportunity
to take a fresh look and decide what we want.

On the pro-revert side,

foldl'new f b xs = b `seq` foldl'old f b xs

which seems considerably less challenging than implementing the lazy
version from scratch with the built-in GHC magic. But there could be times
when that leads to some efficiency problem.
On Jun 10, 2016 12:10 PM, "Bart Massey" <bart.massey at gmail.com> wrote:

> -1 on retaining this. Part of the implied contract of Data.List is that
> all functions be as lazy as possible. Besides, a change that potentially
> breaks old programs that use foldl' seems like a bad idea unless there's a
> really strong reason for it. I don't have an existing example offhand, but
> it seems at least possible that something like
>
>     last = foldl' (flip const) undefined
>
> is out there...
>
> On Fri, Jun 10, 2016 at 5:29 AM David Feuer <david.feuer at gmail.com> wrote:
>
>> The semantics of foldl' for lists were changed between base 4.7 and base
>> 4.8. Specifically, foldl' became strict in the initial value of its
>> accumulator. I opened http://ghc.haskell.org/trac/ghc/ticket/12173 to
>> report this. The change was entirely accidental, according to Joachim
>> Breitner. However, Duncan Coutts indicated he is pleased with the change. I
>> don't personally have a dog in this race, but I feel very strongly about
>> three things:
>>
>> 1. The strictness should be fully documented, both in Haddock and the
>> next Haskell Report (the Haskell 2010 Report does not go into sufficient
>> detail to support either choice).
>>
>> 2. There should be *one* meaning of foldl' in base. Thus the default
>> Foldable instance should match the ones for lists and arrays.
>>
>> 3. The containers package should be consistent with base in this regard.
>> _______________________________________________
>> 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/20160610/0d123969/attachment.html>

From david.feuer at gmail.com  Fri Jun 10 16:45:56 2016
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 10 Jun 2016 12:45:56 -0400
Subject: Request: Add sortOn to Data.Sequence
In-Reply-To: <CAMgWh9sNBbQHH=vZF7hVBy=zCBhR4ugEzHujHJxbuU-LzDTHhg@mail.gmail.com>
References: <67ce4f89-9096-04ee-a8b1-e8cdb0b73633@gmail.com>
 <abbacffb-23b5-2268-df5e-1ab8fb5bc732@gmail.com>
 <CAMgWh9tA_dd9C6_W8==Wn2Mp9AxOuvXbiMq-pWgCgDdUG9+ofQ@mail.gmail.com>
 <CAMgWh9sNBbQHH=vZF7hVBy=zCBhR4ugEzHujHJxbuU-LzDTHhg@mail.gmail.com>
Message-ID: <CAMgWh9vxS9BoyYrT0fpvXea+Nyxqm5kjo+biaG3th+U7MZcnLg@mail.gmail.com>

I think thIs is an interesting idea, generally. There seem to be two
situations that may call for separate functions. If the "key" type can be
stored in an unboxed mutable array, then it seems likely desirable to sort
using such an array. Otherwise, we can use the existing sortBy as suggested.
On Jun 10, 2016 12:30 PM, "Alan Isaac" <alan.isaac at gmail.com> wrote:

REQUEST
-------

The request is to add `sortOn` to Data.Sequence.
`sortOn f` would be equivalent to `sortBy . comparing f`,
but would offer a performance advantage by using a Schwartzian
transform to only evaluate `f` once for each element
in the input sequence.


BACKGROUND
----------

Adding `sortOn` to `Data.List` was proposed at least as early as 2008:
http://www.haskell.org/pipermail/libraries/2008-October/010797.html
It was added in 2014, in response to this feature request:
https://ghc.haskell.org/trac/ghc/ticket/9004


RATIONALES
----------

- convenience
- performance: faster than `sortBy`
- safety: encourages (although does not require) reliance on existing
instances of Ord
- interface consistency (specifically, when comparing to Data.List)

Comment: it is certainly possible to pick at each of these rationales.
See the discussion here:
http://stackoverflow.com/questions/37691898/why-is-sortby-so-oddly-unconstrained-and-why-no-general-sorton/37735121


SCOPE
-----

Introduces no new dependencies except possibly on `Data.Ord.comparing`.


SOLUTIONS
-----------

The implementation in Data.List is::

        sortOn :: Ord b => (a -> b) -> [a] -> [a]
        sortOn f = map snd . sortBy (comparing fst)
                           . map (\x -> let y = f x in y `seq` (y, x))

An analogous implementation is possible for Data.Sequence.
However, this request does not propose a specific implementation.


WHAT MIGHT BREAK
----------------

No anticipated breakage.

_______________________________________________
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/20160610/3ddb790e/attachment-0001.html>

From hvr at gnu.org  Fri Jun 10 16:59:10 2016
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Fri, 10 Jun 2016 18:59:10 +0200
Subject: foldl' semantic change
In-Reply-To: <CAMgWh9taqMe-_1FDsd0OF25Q20h6ZgSg3mkfRq_y5X4P3D2Vsg@mail.gmail.com>
 (David Feuer's message of "Fri, 10 Jun 2016 08:29:47 -0400")
References: <CAMgWh9tpYm+O3C9F7OOk7OtZb-cNHCfW9BRvkYw35_u_9xnbvQ@mail.gmail.com>
 <CAMgWh9vxHKj3DyKfqjgAR+sdY=1qkutNsStvp1tsav11=E7g8g@mail.gmail.com>
 <CAMgWh9thupLpJYvbY=9JBMnS5Rjuq-FKUBSjNDP_snMGzXS7ew@mail.gmail.com>
 <CAMgWh9u2CuUwrLRAs8h5bqEqOq_L8MeNV-TufXUTM2-q8biroQ@mail.gmail.com>
 <CAMgWh9t-Dp206H83UVdO9dsG8ayByQinjX-2k0RO7yLTNq4m7A@mail.gmail.com>
 <CAMgWh9s4HJXZdrZ8b5DGcR3aepHtKCG6VFL43qAVgiePHoYdkQ@mail.gmail.com>
 <CAMgWh9vAG-LeaFKP10RYBOXtKPuGGXqRccRzS1BFhEtSby7JpA@mail.gmail.com>
 <CAMgWh9tybAzy8t9VquGTpDHpRGr4wce+ZvOtmv=rVZrpg9Rh8g@mail.gmail.com>
 <CAMgWh9u0htNNKbskRzZq8sKJ62TkM+bPK2itpJL0Tsf0TMLCsg@mail.gmail.com>
 <CAMgWh9uqmZ8whervOmUTf-q3xHNGe-CGYquse2P+Wo7E5ur3LQ@mail.gmail.com>
 <CAMgWh9veHP3yq5rA1AOwZXjkZML3WrnuAKa8-xehP0Ujq7Y8aw@mail.gmail.com>
 <CAMgWh9v6i4dX_Zj7ub4Y-GeXFw4Hcy6BYuyArtt_u7bAaAdwVA@mail.gmail.com>
 <CAMgWh9txtet0ata=Gq3XcniY5jrio_p=2Y7+iiyn4NUKQA-cOQ@mail.gmail.com>
 <CAMgWh9vNbO8N-fj-W9QNLCxRtW9c3fUQxv4FeYc1LNEwgnuZsw@mail.gmail.com>
 <CAMgWh9taqMe-_1FDsd0OF25Q20h6ZgSg3mkfRq_y5X4P3D2Vsg@mail.gmail.com>
Message-ID: <87d1npkmjl.fsf@gnu.org>

On 2016-06-10 at 14:29:47 +0200, David Feuer wrote:

[...]

> 3. The containers package should be consistent with base in this regard.

for the record, `containers` appears to follow the new stricter
semantics for lists at least since 2014:

  https://mail.haskell.org/pipermail/libraries/2014-November/024081.html


From david.feuer at gmail.com  Fri Jun 10 17:05:50 2016
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 10 Jun 2016 13:05:50 -0400
Subject: foldl' semantic change
In-Reply-To: <87d1npkmjl.fsf@gnu.org>
References: <CAMgWh9tpYm+O3C9F7OOk7OtZb-cNHCfW9BRvkYw35_u_9xnbvQ@mail.gmail.com>
 <CAMgWh9vxHKj3DyKfqjgAR+sdY=1qkutNsStvp1tsav11=E7g8g@mail.gmail.com>
 <CAMgWh9thupLpJYvbY=9JBMnS5Rjuq-FKUBSjNDP_snMGzXS7ew@mail.gmail.com>
 <CAMgWh9u2CuUwrLRAs8h5bqEqOq_L8MeNV-TufXUTM2-q8biroQ@mail.gmail.com>
 <CAMgWh9t-Dp206H83UVdO9dsG8ayByQinjX-2k0RO7yLTNq4m7A@mail.gmail.com>
 <CAMgWh9s4HJXZdrZ8b5DGcR3aepHtKCG6VFL43qAVgiePHoYdkQ@mail.gmail.com>
 <CAMgWh9vAG-LeaFKP10RYBOXtKPuGGXqRccRzS1BFhEtSby7JpA@mail.gmail.com>
 <CAMgWh9tybAzy8t9VquGTpDHpRGr4wce+ZvOtmv=rVZrpg9Rh8g@mail.gmail.com>
 <CAMgWh9u0htNNKbskRzZq8sKJ62TkM+bPK2itpJL0Tsf0TMLCsg@mail.gmail.com>
 <CAMgWh9uqmZ8whervOmUTf-q3xHNGe-CGYquse2P+Wo7E5ur3LQ@mail.gmail.com>
 <CAMgWh9veHP3yq5rA1AOwZXjkZML3WrnuAKa8-xehP0Ujq7Y8aw@mail.gmail.com>
 <CAMgWh9v6i4dX_Zj7ub4Y-GeXFw4Hcy6BYuyArtt_u7bAaAdwVA@mail.gmail.com>
 <CAMgWh9txtet0ata=Gq3XcniY5jrio_p=2Y7+iiyn4NUKQA-cOQ@mail.gmail.com>
 <CAMgWh9vNbO8N-fj-W9QNLCxRtW9c3fUQxv4FeYc1LNEwgnuZsw@mail.gmail.com>
 <CAMgWh9taqMe-_1FDsd0OF25Q20h6ZgSg3mkfRq_y5X4P3D2Vsg@mail.gmail.com>
 <87d1npkmjl.fsf@gnu.org>
Message-ID: <CAMgWh9t0zSr=TZo-fg4xyO6kHV0jbYx2Ewy_QsbV4eEr-JqVLA@mail.gmail.com>

That may be true for most of it, but Data.Sequence has been using the
Foldable defaults. That's going to change in the next version, but unless I
goofed up the semantics remain the same.
On Jun 10, 2016 12:59 PM, "Herbert Valerio Riedel" <hvr at gnu.org> wrote:

> On 2016-06-10 at 14:29:47 +0200, David Feuer wrote:
>
> [...]
>
> > 3. The containers package should be consistent with base in this regard.
>
> for the record, `containers` appears to follow the new stricter
> semantics for lists at least since 2014:
>
>   https://mail.haskell.org/pipermail/libraries/2014-November/024081.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160610/3c4c0034/attachment.html>

From bart.massey at gmail.com  Fri Jun 10 17:40:35 2016
From: bart.massey at gmail.com (Bart Massey)
Date: Fri, 10 Jun 2016 17:40:35 +0000
Subject: foldl' semantic change
In-Reply-To: <CAMgWh9v_rbpFGy5x0U-uaVnL0BaamKRySyrmi_-qqbd_CY2+Bw@mail.gmail.com>
References: <CAMgWh9tpYm+O3C9F7OOk7OtZb-cNHCfW9BRvkYw35_u_9xnbvQ@mail.gmail.com>
 <CAMgWh9vxHKj3DyKfqjgAR+sdY=1qkutNsStvp1tsav11=E7g8g@mail.gmail.com>
 <CAMgWh9thupLpJYvbY=9JBMnS5Rjuq-FKUBSjNDP_snMGzXS7ew@mail.gmail.com>
 <CAMgWh9u2CuUwrLRAs8h5bqEqOq_L8MeNV-TufXUTM2-q8biroQ@mail.gmail.com>
 <CAMgWh9t-Dp206H83UVdO9dsG8ayByQinjX-2k0RO7yLTNq4m7A@mail.gmail.com>
 <CAMgWh9s4HJXZdrZ8b5DGcR3aepHtKCG6VFL43qAVgiePHoYdkQ@mail.gmail.com>
 <CAMgWh9vAG-LeaFKP10RYBOXtKPuGGXqRccRzS1BFhEtSby7JpA@mail.gmail.com>
 <CAMgWh9tybAzy8t9VquGTpDHpRGr4wce+ZvOtmv=rVZrpg9Rh8g@mail.gmail.com>
 <CAMgWh9u0htNNKbskRzZq8sKJ62TkM+bPK2itpJL0Tsf0TMLCsg@mail.gmail.com>
 <CAMgWh9uqmZ8whervOmUTf-q3xHNGe-CGYquse2P+Wo7E5ur3LQ@mail.gmail.com>
 <CAMgWh9veHP3yq5rA1AOwZXjkZML3WrnuAKa8-xehP0Ujq7Y8aw@mail.gmail.com>
 <CAMgWh9v6i4dX_Zj7ub4Y-GeXFw4Hcy6BYuyArtt_u7bAaAdwVA@mail.gmail.com>
 <CAMgWh9txtet0ata=Gq3XcniY5jrio_p=2Y7+iiyn4NUKQA-cOQ@mail.gmail.com>
 <CAMgWh9vNbO8N-fj-W9QNLCxRtW9c3fUQxv4FeYc1LNEwgnuZsw@mail.gmail.com>
 <CAMgWh9taqMe-_1FDsd0OF25Q20h6ZgSg3mkfRq_y5X4P3D2Vsg@mail.gmail.com>
 <CAA6gtpn1y7G0zskdqrVy9wMP+fNQSRxH1bfcbSvRJDsCpu1c8A@mail.gmail.com>
 <CAMgWh9v_rbpFGy5x0U-uaVnL0BaamKRySyrmi_-qqbd_CY2+Bw@mail.gmail.com>
Message-ID: <CAA6gtpm15uKP0uqHaqw+P1mqZjF4Z9pvA1uYU5kaO-dsCqYiTg@mail.gmail.com>

I guess by "packages may have come to rely on it" you mean some situation
where performance is improved by the implicit strictness? It's hard for me
to imagine relying on getting bottom instead of a result. However, it's
also hard for me to imagine relying on foldl' forcing the initial value in
the case of folding on an empty list, and in non-empty list cases the
folding function is likely going to be strict on the accumulator anyhow.
(The last example I gave is an exception to that rule.)

As to the lack of documentation of laziness, my understanding is that
functions in Data.List are expected to be lazy anywhere that their
strictness is not explicitly documented? I don't know if there's actually
language like that in any of the Reports, but the Haddock for Data.List
says, among other things:

> For a general Foldable
<https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Foldable.html#t:Foldable>
 structure this should be semantically identical to,

foldl f z = foldl'
<https://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-OldList.html#v:foldl-39->
f z . toList <https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Foldable.html#v:toList>

which doesn't seem to be actually the case right now, but does seem to be
desirable. (Is the prime on the wrong side here? This seems backward to me,
but I'm easily confused.)

Anyhow, I'll be disappointed if it remains no longer viable to write  last
= foldl' (flip const) undefined  as I did above. It makes the language
harder to teach, and is nonintuitive to me.

On Fri, Jun 10, 2016 at 9:35 AM David Feuer <david.feuer at gmail.com> wrote:

> I would certainly have agreed back when 4.8 was in development. This was
> undoubtedly a breaking change. The fact that it's now been out for some
> time muddies the waters. So does the fact that the strictness has never
> been documented. It seems likely that most packages relying on the old
> behavior have been updated, and it's possible that some may have come to
> rely on it. I see this unfortunate situation as something of an opportunity
> to take a fresh look and decide what we want.
>
> On the pro-revert side,
>
> foldl'new f b xs = b `seq` foldl'old f b xs
>
> which seems considerably less challenging than implementing the lazy
> version from scratch with the built-in GHC magic. But there could be times
> when that leads to some efficiency problem.
> On Jun 10, 2016 12:10 PM, "Bart Massey" <bart.massey at gmail.com> wrote:
>
>> -1 on retaining this. Part of the implied contract of Data.List is that
>> all functions be as lazy as possible. Besides, a change that potentially
>> breaks old programs that use foldl' seems like a bad idea unless there's a
>> really strong reason for it. I don't have an existing example offhand, but
>> it seems at least possible that something like
>>
>>     last = foldl' (flip const) undefined
>>
>> is out there...
>>
>> On Fri, Jun 10, 2016 at 5:29 AM David Feuer <david.feuer at gmail.com>
>> wrote:
>>
>>> The semantics of foldl' for lists were changed between base 4.7 and base
>>> 4.8. Specifically, foldl' became strict in the initial value of its
>>> accumulator. I opened http://ghc.haskell.org/trac/ghc/ticket/12173 to
>>> report this. The change was entirely accidental, according to Joachim
>>> Breitner. However, Duncan Coutts indicated he is pleased with the change. I
>>> don't personally have a dog in this race, but I feel very strongly about
>>> three things:
>>>
>>> 1. The strictness should be fully documented, both in Haddock and the
>>> next Haskell Report (the Haskell 2010 Report does not go into sufficient
>>> detail to support either choice).
>>>
>>> 2. There should be *one* meaning of foldl' in base. Thus the default
>>> Foldable instance should match the ones for lists and arrays.
>>>
>>> 3. The containers package should be consistent with base in this regard.
>>> _______________________________________________
>>> 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/20160610/8618bd48/attachment.html>

From emertens at gmail.com  Fri Jun 10 17:44:51 2016
From: emertens at gmail.com (Eric Mertens)
Date: Fri, 10 Jun 2016 17:44:51 +0000
Subject: [core libraries] Re: foldl' semantic change
In-Reply-To: <CAA6gtpm15uKP0uqHaqw+P1mqZjF4Z9pvA1uYU5kaO-dsCqYiTg@mail.gmail.com>
References: <CAMgWh9tpYm+O3C9F7OOk7OtZb-cNHCfW9BRvkYw35_u_9xnbvQ@mail.gmail.com>
 <CAMgWh9vxHKj3DyKfqjgAR+sdY=1qkutNsStvp1tsav11=E7g8g@mail.gmail.com>
 <CAMgWh9thupLpJYvbY=9JBMnS5Rjuq-FKUBSjNDP_snMGzXS7ew@mail.gmail.com>
 <CAMgWh9u2CuUwrLRAs8h5bqEqOq_L8MeNV-TufXUTM2-q8biroQ@mail.gmail.com>
 <CAMgWh9t-Dp206H83UVdO9dsG8ayByQinjX-2k0RO7yLTNq4m7A@mail.gmail.com>
 <CAMgWh9s4HJXZdrZ8b5DGcR3aepHtKCG6VFL43qAVgiePHoYdkQ@mail.gmail.com>
 <CAMgWh9vAG-LeaFKP10RYBOXtKPuGGXqRccRzS1BFhEtSby7JpA@mail.gmail.com>
 <CAMgWh9tybAzy8t9VquGTpDHpRGr4wce+ZvOtmv=rVZrpg9Rh8g@mail.gmail.com>
 <CAMgWh9u0htNNKbskRzZq8sKJ62TkM+bPK2itpJL0Tsf0TMLCsg@mail.gmail.com>
 <CAMgWh9uqmZ8whervOmUTf-q3xHNGe-CGYquse2P+Wo7E5ur3LQ@mail.gmail.com>
 <CAMgWh9veHP3yq5rA1AOwZXjkZML3WrnuAKa8-xehP0Ujq7Y8aw@mail.gmail.com>
 <CAMgWh9v6i4dX_Zj7ub4Y-GeXFw4Hcy6BYuyArtt_u7bAaAdwVA@mail.gmail.com>
 <CAMgWh9txtet0ata=Gq3XcniY5jrio_p=2Y7+iiyn4NUKQA-cOQ@mail.gmail.com>
 <CAMgWh9vNbO8N-fj-W9QNLCxRtW9c3fUQxv4FeYc1LNEwgnuZsw@mail.gmail.com>
 <CAMgWh9taqMe-_1FDsd0OF25Q20h6ZgSg3mkfRq_y5X4P3D2Vsg@mail.gmail.com>
 <CAA6gtpn1y7G0zskdqrVy9wMP+fNQSRxH1bfcbSvRJDsCpu1c8A@mail.gmail.com>
 <CAMgWh9v_rbpFGy5x0U-uaVnL0BaamKRySyrmi_-qqbd_CY2+Bw@mail.gmail.com>
 <CAA6gtpm15uKP0uqHaqw+P1mqZjF4Z9pvA1uYU5kaO-dsCqYiTg@mail.gmail.com>
Message-ID: <CALya091SZA-phepTBRUkYpPnAVm0fEWONDzzjDiR+=CR99tAsg@mail.gmail.com>

Regarding implementing last with foldl, this is exactly the time you would
not use foldl' but would only use foldl. Implementing last with foldl' will
force all of the elements of the list on the way to returning the last
element.

Best regards,
Eric Mertens
glguy

On Fri, Jun 10, 2016 at 10:40 AM Bart Massey <bart.massey at gmail.com> wrote:

> I guess by "packages may have come to rely on it" you mean some situation
> where performance is improved by the implicit strictness? It's hard for me
> to imagine relying on getting bottom instead of a result. However, it's
> also hard for me to imagine relying on foldl' forcing the initial value in
> the case of folding on an empty list, and in non-empty list cases the
> folding function is likely going to be strict on the accumulator anyhow.
> (The last example I gave is an exception to that rule.)
>
> As to the lack of documentation of laziness, my understanding is that
> functions in Data.List are expected to be lazy anywhere that their
> strictness is not explicitly documented? I don't know if there's actually
> language like that in any of the Reports, but the Haddock for Data.List
> says, among other things:
>
> > For a general Foldable
> <https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Foldable.html#t:Foldable>
>  structure this should be semantically identical to,
>
> foldl f z = foldl' <https://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-OldList.html#v:foldl-39-> f z . toList <https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Foldable.html#v:toList>
>
> which doesn't seem to be actually the case right now, but does seem to be
> desirable. (Is the prime on the wrong side here? This seems backward to me,
> but I'm easily confused.)
>
> Anyhow, I'll be disappointed if it remains no longer viable to write  last
> = foldl' (flip const) undefined  as I did above. It makes the language
> harder to teach, and is nonintuitive to me.
>
> On Fri, Jun 10, 2016 at 9:35 AM David Feuer <david.feuer at gmail.com> wrote:
>
>> I would certainly have agreed back when 4.8 was in development. This was
>> undoubtedly a breaking change. The fact that it's now been out for some
>> time muddies the waters. So does the fact that the strictness has never
>> been documented. It seems likely that most packages relying on the old
>> behavior have been updated, and it's possible that some may have come to
>> rely on it. I see this unfortunate situation as something of an opportunity
>> to take a fresh look and decide what we want.
>>
>> On the pro-revert side,
>>
>> foldl'new f b xs = b `seq` foldl'old f b xs
>>
>> which seems considerably less challenging than implementing the lazy
>> version from scratch with the built-in GHC magic. But there could be times
>> when that leads to some efficiency problem.
>> On Jun 10, 2016 12:10 PM, "Bart Massey" <bart.massey at gmail.com> wrote:
>>
>>> -1 on retaining this. Part of the implied contract of Data.List is that
>>> all functions be as lazy as possible. Besides, a change that potentially
>>> breaks old programs that use foldl' seems like a bad idea unless there's a
>>> really strong reason for it. I don't have an existing example offhand, but
>>> it seems at least possible that something like
>>>
>>>     last = foldl' (flip const) undefined
>>>
>>> is out there...
>>>
>>> On Fri, Jun 10, 2016 at 5:29 AM David Feuer <david.feuer at gmail.com>
>>> wrote:
>>>
>>>> The semantics of foldl' for lists were changed between base 4.7 and
>>>> base 4.8. Specifically, foldl' became strict in the initial value of its
>>>> accumulator. I opened http://ghc.haskell.org/trac/ghc/ticket/12173 to
>>>> report this. The change was entirely accidental, according to Joachim
>>>> Breitner. However, Duncan Coutts indicated he is pleased with the change. I
>>>> don't personally have a dog in this race, but I feel very strongly about
>>>> three things:
>>>>
>>>> 1. The strictness should be fully documented, both in Haddock and the
>>>> next Haskell Report (the Haskell 2010 Report does not go into sufficient
>>>> detail to support either choice).
>>>>
>>>> 2. There should be *one* meaning of foldl' in base. Thus the default
>>>> Foldable instance should match the ones for lists and arrays.
>>>>
>>>> 3. The containers package should be consistent with base in this regard.
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "haskell-core-libraries" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to haskell-core-libraries+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160610/6e6f7237/attachment-0001.html>

From winterkoninkje at gmail.com  Fri Jun 10 22:50:19 2016
From: winterkoninkje at gmail.com (wren romano)
Date: Fri, 10 Jun 2016 18:50:19 -0400
Subject: foldl' semantic change
In-Reply-To: <CAA6gtpm15uKP0uqHaqw+P1mqZjF4Z9pvA1uYU5kaO-dsCqYiTg@mail.gmail.com>
References: <CAMgWh9tpYm+O3C9F7OOk7OtZb-cNHCfW9BRvkYw35_u_9xnbvQ@mail.gmail.com>
 <CAMgWh9vxHKj3DyKfqjgAR+sdY=1qkutNsStvp1tsav11=E7g8g@mail.gmail.com>
 <CAMgWh9thupLpJYvbY=9JBMnS5Rjuq-FKUBSjNDP_snMGzXS7ew@mail.gmail.com>
 <CAMgWh9u2CuUwrLRAs8h5bqEqOq_L8MeNV-TufXUTM2-q8biroQ@mail.gmail.com>
 <CAMgWh9t-Dp206H83UVdO9dsG8ayByQinjX-2k0RO7yLTNq4m7A@mail.gmail.com>
 <CAMgWh9s4HJXZdrZ8b5DGcR3aepHtKCG6VFL43qAVgiePHoYdkQ@mail.gmail.com>
 <CAMgWh9vAG-LeaFKP10RYBOXtKPuGGXqRccRzS1BFhEtSby7JpA@mail.gmail.com>
 <CAMgWh9tybAzy8t9VquGTpDHpRGr4wce+ZvOtmv=rVZrpg9Rh8g@mail.gmail.com>
 <CAMgWh9u0htNNKbskRzZq8sKJ62TkM+bPK2itpJL0Tsf0TMLCsg@mail.gmail.com>
 <CAMgWh9uqmZ8whervOmUTf-q3xHNGe-CGYquse2P+Wo7E5ur3LQ@mail.gmail.com>
 <CAMgWh9veHP3yq5rA1AOwZXjkZML3WrnuAKa8-xehP0Ujq7Y8aw@mail.gmail.com>
 <CAMgWh9v6i4dX_Zj7ub4Y-GeXFw4Hcy6BYuyArtt_u7bAaAdwVA@mail.gmail.com>
 <CAMgWh9txtet0ata=Gq3XcniY5jrio_p=2Y7+iiyn4NUKQA-cOQ@mail.gmail.com>
 <CAMgWh9vNbO8N-fj-W9QNLCxRtW9c3fUQxv4FeYc1LNEwgnuZsw@mail.gmail.com>
 <CAMgWh9taqMe-_1FDsd0OF25Q20h6ZgSg3mkfRq_y5X4P3D2Vsg@mail.gmail.com>
 <CAA6gtpn1y7G0zskdqrVy9wMP+fNQSRxH1bfcbSvRJDsCpu1c8A@mail.gmail.com>
 <CAMgWh9v_rbpFGy5x0U-uaVnL0BaamKRySyrmi_-qqbd_CY2+Bw@mail.gmail.com>
 <CAA6gtpm15uKP0uqHaqw+P1mqZjF4Z9pvA1uYU5kaO-dsCqYiTg@mail.gmail.com>
Message-ID: <CABUjdS4SkcX9bwPpEGC1KT00jy-dW-Z0ACDJ++ccUfkGTOwdxQ@mail.gmail.com>

On Fri, Jun 10, 2016 at 1:40 PM, Bart Massey <bart.massey at gmail.com> wrote:
> It's hard for me to imagine relying on getting bottom instead of a result.

Thanks to the presence of extensible exceptions, some people may do
things like (foldl' f (throw blah)) and then catch the exception
further up. It's terrible, I know. Using explicit continuations would
be much cleaner. But still, it is what it is


> However, it's also
> hard for me to imagine relying on foldl' forcing the initial value in the
> case of folding on an empty list, and in non-empty list cases the folding
> function is likely going to be strict on the accumulator anyhow.

The main issue I see here is a sort of inference issue. That is, if
the initial value to fold' is marked as lazy then we might build up
some huge thunk which must in practice actually get forced; whereas if
the initial value is strict then we can percolate the knowledge of
that strictness further up, potentially evaluating things more eagerly
and thus avoiding the overhead of thunking, allocation, etc.

-- 
Live well,
~wren

From ekmett at gmail.com  Sat Jun 11 02:13:12 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 10 Jun 2016 22:13:12 -0400
Subject: Request: Add sortOn to Data.Sequence
In-Reply-To: <CAMgWh9vxS9BoyYrT0fpvXea+Nyxqm5kjo+biaG3th+U7MZcnLg@mail.gmail.com>
References: <67ce4f89-9096-04ee-a8b1-e8cdb0b73633@gmail.com>
 <abbacffb-23b5-2268-df5e-1ab8fb5bc732@gmail.com>
 <CAMgWh9tA_dd9C6_W8==Wn2Mp9AxOuvXbiMq-pWgCgDdUG9+ofQ@mail.gmail.com>
 <CAMgWh9sNBbQHH=vZF7hVBy=zCBhR4ugEzHujHJxbuU-LzDTHhg@mail.gmail.com>
 <CAMgWh9vxS9BoyYrT0fpvXea+Nyxqm5kjo+biaG3th+U7MZcnLg@mail.gmail.com>
Message-ID: <CAJumaK9SiWCDyqs60q5tZ3ntFLFkdUM+BQMMvDFuv3BnpOmicw@mail.gmail.com>

We've already accepted a similar addition to Data.List, so I see no harm in
having an implementation for Data.Sequence.

-Edward

On Fri, Jun 10, 2016 at 12:45 PM, David Feuer <david.feuer at gmail.com> wrote:

> I think thIs is an interesting idea, generally. There seem to be two
> situations that may call for separate functions. If the "key" type can be
> stored in an unboxed mutable array, then it seems likely desirable to sort
> using such an array. Otherwise, we can use the existing sortBy as suggested.
> On Jun 10, 2016 12:30 PM, "Alan Isaac" <alan.isaac at gmail.com> wrote:
>
> REQUEST
> -------
>
> The request is to add `sortOn` to Data.Sequence.
> `sortOn f` would be equivalent to `sortBy . comparing f`,
> but would offer a performance advantage by using a Schwartzian
> transform to only evaluate `f` once for each element
> in the input sequence.
>
>
> BACKGROUND
> ----------
>
> Adding `sortOn` to `Data.List` was proposed at least as early as 2008:
> http://www.haskell.org/pipermail/libraries/2008-October/010797.html
> It was added in 2014, in response to this feature request:
> https://ghc.haskell.org/trac/ghc/ticket/9004
>
>
> RATIONALES
> ----------
>
> - convenience
> - performance: faster than `sortBy`
> - safety: encourages (although does not require) reliance on existing
> instances of Ord
> - interface consistency (specifically, when comparing to Data.List)
>
> Comment: it is certainly possible to pick at each of these rationales.
> See the discussion here:
>
> http://stackoverflow.com/questions/37691898/why-is-sortby-so-oddly-unconstrained-and-why-no-general-sorton/37735121
>
>
> SCOPE
> -----
>
> Introduces no new dependencies except possibly on `Data.Ord.comparing`.
>
>
> SOLUTIONS
> -----------
>
> The implementation in Data.List is::
>
>         sortOn :: Ord b => (a -> b) -> [a] -> [a]
>         sortOn f = map snd . sortBy (comparing fst)
>                            . map (\x -> let y = f x in y `seq` (y, x))
>
> An analogous implementation is possible for Data.Sequence.
> However, this request does not propose a specific implementation.
>
>
> WHAT MIGHT BREAK
> ----------------
>
> No anticipated breakage.
>
> _______________________________________________
> 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/20160610/04115445/attachment.html>

From mle+hs at mega-nerd.com  Sun Jun 12 06:29:29 2016
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Sun, 12 Jun 2016 16:29:29 +1000
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
Message-ID: <20160612162929.ee5d6ccea0c76c971c3cc49e@mega-nerd.com>

Anton Felix Lorenzen wrote:

> When working with Either,
> I am often missing two simple functions:
> fromRight :: Either a b -> b
> fromLeft  :: Either a b -> a
> 
> It has been implemented a couple of times:
> http://hayoo.fh-wedel.de/?query=fromRight
> 
> But I don't want to depend on yet another library
> for such a basic function.
> 
> Could it be added?

-1 on the addition of yet another partial function.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From ekmett at gmail.com  Sun Jun 12 19:51:11 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 12 Jun 2016 15:51:11 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <20160612162929.ee5d6ccea0c76c971c3cc49e@mega-nerd.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <20160612162929.ee5d6ccea0c76c971c3cc49e@mega-nerd.com>
Message-ID: <CAJumaK_iVab5=ezqCgHCENTjybT5sygW-BKeiDi4R4GzTw7ccA@mail.gmail.com>

Putting on my CLC hat to summarize the talk so far into a concrete plan:

It looks like there is sufficient consensus to add the

fromLeft :: a -> Either a b -> a
fromRight :: b -> Either a b -> b

variants to Data.Either, so let's do that.

This avoids partiality concerns, and seems to have broad support. I'll
modify the `either` package to re-export them once they make it into base
to avoid import conflicts.

Does someone want to bang out a patch?

-Edward

On Sun, Jun 12, 2016 at 2:29 AM, Erik de Castro Lopo <mle+hs at mega-nerd.com>
wrote:

> Anton Felix Lorenzen wrote:
>
> > When working with Either,
> > I am often missing two simple functions:
> > fromRight :: Either a b -> b
> > fromLeft  :: Either a b -> a
> >
> > It has been implemented a couple of times:
> > http://hayoo.fh-wedel.de/?query=fromRight
> >
> > But I don't want to depend on yet another library
> > for such a basic function.
> >
> > Could it be added?
>
> -1 on the addition of yet another partial function.
>
> Erik
> --
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> _______________________________________________
> 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/20160612/f5a5101c/attachment.html>

From haskell at marcelfourne.de  Wed Jun 15 07:13:32 2016
From: haskell at marcelfourne.de (Marcel =?UTF-8?B?Rm91cm7DqQ==?=)
Date: Wed, 15 Jun 2016 09:13:32 +0200
Subject: ANN: eccrypto, aka Hecc, hF2
Message-ID: <20160615091332.334d7d97@rechner>

Dear Haskell Community!

It was a long~ish time ago I released hecc[1], which had an unfortunate
but funny (to me) name, later together with hF2[2]. Since I have neither
released hyperelliptic curve crypto support, nor my pairing based crypto,
a generalising change in names would be in order.

Today I am releasing eccrypto[3], which contains the code of both (to
allow easier refactoring of new ideas) and something new:
A pure Haskell, timing-attack resistant Ed25519[4]
implementation! ...well, a very rough one at least. The code is not
"done", gives wrong results, is _very_ slow, but it might serve as
reading material as well as a primer what I plan to do in the future.
I do not plan to add embedded C or assembler code, but plan to make the
code comparatively fast to some common implementations as well as
timing attack resistant (see: [5]), even if it will never be as fast as
the best code used in contemporary benchmarks.

Sadly, due to health issues, I am not able to work on said code and
have not been for a time longer than I care to admit.

All comments are welcome, but I will not be able to guarantee answers. ;)

Best of wishes to a thriving community,
Marcel Fourn?


[1]: https://hackage.haskell.org/package/hecc
[2]: https://hackage.haskell.org/package/hF2
[3]: https://hackage.haskell.org/package/eccrypto
[4]: https://ed25519.cr.yp.to/
[5]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118213.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160615/e4a264eb/attachment.sig>

From lemming at henning-thielemann.de  Sat Jun 18 13:59:55 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 18 Jun 2016 15:59:55 +0200 (CEST)
Subject: bit sets in IntSet vs. Integer
Message-ID: <alpine.DEB.2.02.1606181154400.9798@sputnik>


In my set-cover package I make extensive use of bit vectors. I tested both 
IntSet and Integer for this purpose. In GHC-7.4.2 Integer was visibly 
faster than IntSet, but in GHC-7.8.4 and later, IntSet clearly wins over 
Integer. I guess this can be attributed to IntSet using BitMaps at the 
leaves since containers-0.5. However, on a 64-bit machine a BitMap is a 
Word64. I wondered whether we could get further speedup by using a vector 
type. E.g. AVX processors could perform bit manipulations on 256 bit 
words. Do the bit operations on Integer make use of vector instructions?

From carter.schonwald at gmail.com  Sun Jun 19 01:45:04 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 18 Jun 2016 21:45:04 -0400
Subject: bit sets in IntSet vs. Integer
In-Reply-To: <alpine.DEB.2.02.1606181154400.9798@sputnik>
References: <alpine.DEB.2.02.1606181154400.9798@sputnik>
Message-ID: <CAHYVw0yihqCaqvW+4Axu7OQyZytTF=jraad_1ny7AxX7idt5KQ@mail.gmail.com>

Henning: I suggest you read the gmp source and tell us :)

On Saturday, June 18, 2016, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> In my set-cover package I make extensive use of bit vectors. I tested both
> IntSet and Integer for this purpose. In GHC-7.4.2 Integer was visibly
> faster than IntSet, but in GHC-7.8.4 and later, IntSet clearly wins over
> Integer. I guess this can be attributed to IntSet using BitMaps at the
> leaves since containers-0.5. However, on a 64-bit machine a BitMap is a
> Word64. I wondered whether we could get further speedup by using a vector
> type. E.g. AVX processors could perform bit manipulations on 256 bit words.
> Do the bit operations on Integer make use of vector instructions?
> _______________________________________________
> 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/20160618/fc279a5c/attachment.html>

From lemming at henning-thielemann.de  Sun Jun 19 06:52:17 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 19 Jun 2016 08:52:17 +0200 (CEST)
Subject: bit sets in IntSet vs. Integer
In-Reply-To: <CAHYVw0yihqCaqvW+4Axu7OQyZytTF=jraad_1ny7AxX7idt5KQ@mail.gmail.com>
References: <alpine.DEB.2.02.1606181154400.9798@sputnik>
 <CAHYVw0yihqCaqvW+4Axu7OQyZytTF=jraad_1ny7AxX7idt5KQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1606190843440.9404@sputnik>


On Sat, 18 Jun 2016, Carter Schonwald wrote:

> Henning: I suggest you read the gmp source and tell us :)

I hoped you have already done so. :-)

Does GHC call GMP for bit operations on Integer?
Aha, yes, it calls integer_gmp_mpn_and_n for (.&.) :
    https://hackage.haskell.org/package/integer-gmp-1.0.0.1/docs/src/GHC.Integer.Type.html#c_mpn_and_n

From david.feuer at gmail.com  Sun Jun 19 13:35:21 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 19 Jun 2016 09:35:21 -0400
Subject: bit sets in IntSet vs. Integer
In-Reply-To: <alpine.DEB.2.02.1606190843440.9404@sputnik>
References: <alpine.DEB.2.02.1606181154400.9798@sputnik>
 <CAHYVw0yihqCaqvW+4Axu7OQyZytTF=jraad_1ny7AxX7idt5KQ@mail.gmail.com>
 <alpine.DEB.2.02.1606190843440.9404@sputnik>
Message-ID: <CAMgWh9v2cX3VuV5N4f6Z+LwW02Ei3L0QZfhFehKG3VZ_HQA-QQ@mail.gmail.com>

I know that Sergei Lebedev did quite a bit of work (for the bitset package)
optimizing certain Integer bit operations. That code doesn't work with the
new Integer, but it can probably be adapted.

On Sat, 18 Jun 2016, Carter Schonwald wrote:

> Henning: I suggest you read the gmp source and tell us :)

I hoped you have already done so. :-)

Does GHC call GMP for bit operations on Integer?
Aha, yes, it calls integer_gmp_mpn_and_n for (.&.) :

https://hackage.haskell.org/package/integer-gmp-1.0.0.1/docs/src/GHC.Integer.Type.html#c_mpn_and_n
_______________________________________________
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/20160619/48cda8c0/attachment.html>

From lemming at henning-thielemann.de  Sun Jun 19 14:45:48 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 19 Jun 2016 16:45:48 +0200 (CEST)
Subject: bit sets in IntSet vs. Integer
In-Reply-To: <CAMgWh9v2cX3VuV5N4f6Z+LwW02Ei3L0QZfhFehKG3VZ_HQA-QQ@mail.gmail.com>
References: <alpine.DEB.2.02.1606181154400.9798@sputnik>
 <CAHYVw0yihqCaqvW+4Axu7OQyZytTF=jraad_1ny7AxX7idt5KQ@mail.gmail.com>
 <alpine.DEB.2.02.1606190843440.9404@sputnik>
 <CAMgWh9v2cX3VuV5N4f6Z+LwW02Ei3L0QZfhFehKG3VZ_HQA-QQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1606191644090.9404@sputnik>


On Sun, 19 Jun 2016, David Feuer wrote:

> I know that Sergei Lebedev did quite a bit of work (for the bitset 
> package) optimizing certain Integer bit operations. That code doesn't 
> work with the new Integer, but it can probably be adapted.

>From a quick look, it simply gives names of set operation to existing 
Data.Bits methods on Integer. I cannot see much custom optimizations.

From david.feuer at gmail.com  Sun Jun 19 15:20:47 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 19 Jun 2016 11:20:47 -0400
Subject: bit sets in IntSet vs. Integer
In-Reply-To: <alpine.DEB.2.02.1606191644090.9404@sputnik>
References: <alpine.DEB.2.02.1606181154400.9798@sputnik>
 <CAHYVw0yihqCaqvW+4Axu7OQyZytTF=jraad_1ny7AxX7idt5KQ@mail.gmail.com>
 <alpine.DEB.2.02.1606190843440.9404@sputnik>
 <CAMgWh9v2cX3VuV5N4f6Z+LwW02Ei3L0QZfhFehKG3VZ_HQA-QQ@mail.gmail.com>
 <alpine.DEB.2.02.1606191644090.9404@sputnik>
Message-ID: <CAMgWh9u=_xTwcLareJiF+OTy689uxwkDjUjEzXgNoUW9RN-HjQ@mail.gmail.com>

Your quick look is insufficient. There are custom implementations of bit
setting and clearing operations that use GMP primitives instead of the
Data.Bits defaults.
On Jun 19, 2016 10:45 AM, "Henning Thielemann" <
lemming at henning-thielemann.de> wrote:

>
> On Sun, 19 Jun 2016, David Feuer wrote:
>
> I know that Sergei Lebedev did quite a bit of work (for the bitset
>> package) optimizing certain Integer bit operations. That code doesn't work
>> with the new Integer, but it can probably be adapted.
>>
>
> From a quick look, it simply gives names of set operation to existing
> Data.Bits methods on Integer. I cannot see much custom optimizations.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160619/ce91196b/attachment.html>

From lemming at henning-thielemann.de  Sun Jun 19 15:25:58 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 19 Jun 2016 17:25:58 +0200 (CEST)
Subject: bit sets in IntSet vs. Integer
In-Reply-To: <CAMgWh9u=_xTwcLareJiF+OTy689uxwkDjUjEzXgNoUW9RN-HjQ@mail.gmail.com>
References: <alpine.DEB.2.02.1606181154400.9798@sputnik>
 <CAHYVw0yihqCaqvW+4Axu7OQyZytTF=jraad_1ny7AxX7idt5KQ@mail.gmail.com>
 <alpine.DEB.2.02.1606190843440.9404@sputnik>
 <CAMgWh9v2cX3VuV5N4f6Z+LwW02Ei3L0QZfhFehKG3VZ_HQA-QQ@mail.gmail.com>
 <alpine.DEB.2.02.1606191644090.9404@sputnik>
 <CAMgWh9u=_xTwcLareJiF+OTy689uxwkDjUjEzXgNoUW9RN-HjQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1606191724150.9404@sputnik>


On Sun, 19 Jun 2016, David Feuer wrote:

> Your quick look is insufficient. There are custom implementations of bit 
> setting and clearing operations that use GMP primitives instead of the 
> Data.Bits defaults.

I have seen them, but the expensive operations like 'union' and 
'difference' are not optimized, right? They would benefit from CPU vector 
instructions.

From ryan.gl.scott at gmail.com  Sun Jun 19 20:40:30 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Sun, 19 Jun 2016 16:40:30 -0400
Subject: Proposal: add ReadPrec-based functions to Read1/Read2
Message-ID: <CADdQpRAcdCyq9KkChg4StBJ026jxrKSfyQbfPv8PQ1euDKEQtA@mail.gmail.com>

GHC 8.0 added the Data.Functor.Classes module [1] to base, and with it
the Read1 and Read2 typeclasses. The current definition of Read1 is
this:

    class Read1 f where
        liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a)
        liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a]

There's a pretty big problem with this definition: it uses ReadS (a
synonym for String -> [(a, String)]). This sort of parser is very slow
(the docs even admit as such [2]), and moreover, the actual Read
typeclass on which Read1 is based tries to avoid using it whenever
possible.

The Read typeclass has this definition currently:

    class Read a where
        readsPrec    :: Int -> ReadS a
        readList     :: ReadS [a]
        readPrec     :: ReadPrec a
        readListPrec :: ReadPrec [a]

Where ReadPrec is a much more efficient parser datatype. When deriving
Read instances, GHC defines them in terms of readPrec, and gives the
other methods default definitions that leverage readPrec.

For the sake of consistency, I propose adding analogous methods to
Read1 and Read2 that use the ReadPrec datatype. For example, here is
how I would change Read1:

    class Read1 f where
        liftReadsPrec    :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a)
        liftReadList     :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a]
        liftReadPrec     :: ReadPrec a -> ReadPrec [a] -> ReadPrec (f a)
        liftReadListPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec [f a]

And similarly for Read2. Here is a full gist [3] with a sketch of what
the new Read1/Read2 definitions would look like, including what the
default definitions of the other methods would be.

Ryan S.
-----
[1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Functor-Classes.html
[2] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-ParserCombinators-ReadP.html#t:ReadS
[3] https://gist.github.com/RyanGlScott/7cdd11d6aa878e4229acf1a682beb1fc

From carter.schonwald at gmail.com  Sun Jun 19 22:56:16 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 19 Jun 2016 18:56:16 -0400
Subject: Proposal: add ReadPrec-based functions to Read1/Read2
In-Reply-To: <CADdQpRAcdCyq9KkChg4StBJ026jxrKSfyQbfPv8PQ1euDKEQtA@mail.gmail.com>
References: <CADdQpRAcdCyq9KkChg4StBJ026jxrKSfyQbfPv8PQ1euDKEQtA@mail.gmail.com>
Message-ID: <CAHYVw0zWNTs8OpUaS7uGoWX899gqGtO1qr+Y6Gsn=U7=fgdZ8A@mail.gmail.com>

I'm always in favor of providing algorithmicly better interfaces, so
barring me learning that there's doe thing even better we should do , +1 :)

On Sunday, June 19, 2016, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> GHC 8.0 added the Data.Functor.Classes module [1] to base, and with it
> the Read1 and Read2 typeclasses. The current definition of Read1 is
> this:
>
>     class Read1 f where
>         liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f
> a)
>         liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a]
>
> There's a pretty big problem with this definition: it uses ReadS (a
> synonym for String -> [(a, String)]). This sort of parser is very slow
> (the docs even admit as such [2]), and moreover, the actual Read
> typeclass on which Read1 is based tries to avoid using it whenever
> possible.
>
> The Read typeclass has this definition currently:
>
>     class Read a where
>         readsPrec    :: Int -> ReadS a
>         readList     :: ReadS [a]
>         readPrec     :: ReadPrec a
>         readListPrec :: ReadPrec [a]
>
> Where ReadPrec is a much more efficient parser datatype. When deriving
> Read instances, GHC defines them in terms of readPrec, and gives the
> other methods default definitions that leverage readPrec.
>
> For the sake of consistency, I propose adding analogous methods to
> Read1 and Read2 that use the ReadPrec datatype. For example, here is
> how I would change Read1:
>
>     class Read1 f where
>         liftReadsPrec    :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS
> (f a)
>         liftReadList     :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a]
>         liftReadPrec     :: ReadPrec a -> ReadPrec [a] -> ReadPrec (f a)
>         liftReadListPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec [f a]
>
> And similarly for Read2. Here is a full gist [3] with a sketch of what
> the new Read1/Read2 definitions would look like, including what the
> default definitions of the other methods would be.
>
> Ryan S.
> -----
> [1]
> http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Functor-Classes.html
> [2]
> http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-ParserCombinators-ReadP.html#t:ReadS
> [3] https://gist.github.com/RyanGlScott/7cdd11d6aa878e4229acf1a682beb1fc
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160619/0cbadb33/attachment.html>

From carter.schonwald at gmail.com  Sun Jun 19 22:58:11 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 19 Jun 2016 18:58:11 -0400
Subject: bit sets in IntSet vs. Integer
In-Reply-To: <alpine.DEB.2.02.1606191724150.9404@sputnik>
References: <alpine.DEB.2.02.1606181154400.9798@sputnik>
 <CAHYVw0yihqCaqvW+4Axu7OQyZytTF=jraad_1ny7AxX7idt5KQ@mail.gmail.com>
 <alpine.DEB.2.02.1606190843440.9404@sputnik>
 <CAMgWh9v2cX3VuV5N4f6Z+LwW02Ei3L0QZfhFehKG3VZ_HQA-QQ@mail.gmail.com>
 <alpine.DEB.2.02.1606191644090.9404@sputnik>
 <CAMgWh9u=_xTwcLareJiF+OTy689uxwkDjUjEzXgNoUW9RN-HjQ@mail.gmail.com>
 <alpine.DEB.2.02.1606191724150.9404@sputnik>
Message-ID: <CAHYVw0xRoUQyTPXEZ3zOsa-0c1iRvwgv2aD=yXYbHytVnsgrHw@mail.gmail.com>

Did you read the code for the underlying gmp c code? And associated c APIs?

I'm told that part of the value of the new style gmp binding is that it
should be safer to link to any missing gmp functionality you may wish to
use.

On Sunday, June 19, 2016, Henning Thielemann <lemming at henning-thielemann.de>
wrote:

>
> On Sun, 19 Jun 2016, David Feuer wrote:
>
> Your quick look is insufficient. There are custom implementations of bit
>> setting and clearing operations that use GMP primitives instead of the
>> Data.Bits defaults.
>>
>
> I have seen them, but the expensive operations like 'union' and
> 'difference' are not optimized, right? They would benefit from CPU vector
> instructions.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160619/5b31773e/attachment-0001.html>

From david.feuer at gmail.com  Sun Jun 19 23:00:53 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 19 Jun 2016 19:00:53 -0400
Subject: bit sets in IntSet vs. Integer
In-Reply-To: <CAHYVw0xRoUQyTPXEZ3zOsa-0c1iRvwgv2aD=yXYbHytVnsgrHw@mail.gmail.com>
References: <alpine.DEB.2.02.1606181154400.9798@sputnik>
 <CAHYVw0yihqCaqvW+4Axu7OQyZytTF=jraad_1ny7AxX7idt5KQ@mail.gmail.com>
 <alpine.DEB.2.02.1606190843440.9404@sputnik>
 <CAMgWh9v2cX3VuV5N4f6Z+LwW02Ei3L0QZfhFehKG3VZ_HQA-QQ@mail.gmail.com>
 <alpine.DEB.2.02.1606191644090.9404@sputnik>
 <CAMgWh9u=_xTwcLareJiF+OTy689uxwkDjUjEzXgNoUW9RN-HjQ@mail.gmail.com>
 <alpine.DEB.2.02.1606191724150.9404@sputnik>
 <CAHYVw0xRoUQyTPXEZ3zOsa-0c1iRvwgv2aD=yXYbHytVnsgrHw@mail.gmail.com>
Message-ID: <CAMgWh9v533_F-6hHt6OMMFCjD8q7EuA-sp6NX3qzUGme8JaoRQ@mail.gmail.com>

How does that excuse an inefficient implementation of Bits Integer?
On Jun 19, 2016 6:58 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
wrote:

> Did you read the code for the underlying gmp c code? And associated c
> APIs?
>
> I'm told that part of the value of the new style gmp binding is that it
> should be safer to link to any missing gmp functionality you may wish to
> use.
>
> On Sunday, June 19, 2016, Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>
>>
>> On Sun, 19 Jun 2016, David Feuer wrote:
>>
>> Your quick look is insufficient. There are custom implementations of bit
>>> setting and clearing operations that use GMP primitives instead of the
>>> Data.Bits defaults.
>>>
>>
>> I have seen them, but the expensive operations like 'union' and
>> 'difference' are not optimized, right? They would benefit from CPU vector
>> instructions.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160619/a1c69f4b/attachment.html>

From carter.schonwald at gmail.com  Mon Jun 20 00:54:21 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 19 Jun 2016 20:54:21 -0400
Subject: bit sets in IntSet vs. Integer
In-Reply-To: <CAMgWh9v533_F-6hHt6OMMFCjD8q7EuA-sp6NX3qzUGme8JaoRQ@mail.gmail.com>
References: <alpine.DEB.2.02.1606181154400.9798@sputnik>
 <CAHYVw0yihqCaqvW+4Axu7OQyZytTF=jraad_1ny7AxX7idt5KQ@mail.gmail.com>
 <alpine.DEB.2.02.1606190843440.9404@sputnik>
 <CAMgWh9v2cX3VuV5N4f6Z+LwW02Ei3L0QZfhFehKG3VZ_HQA-QQ@mail.gmail.com>
 <alpine.DEB.2.02.1606191644090.9404@sputnik>
 <CAMgWh9u=_xTwcLareJiF+OTy689uxwkDjUjEzXgNoUW9RN-HjQ@mail.gmail.com>
 <alpine.DEB.2.02.1606191724150.9404@sputnik>
 <CAHYVw0xRoUQyTPXEZ3zOsa-0c1iRvwgv2aD=yXYbHytVnsgrHw@mail.gmail.com>
 <CAMgWh9v533_F-6hHt6OMMFCjD8q7EuA-sp6NX3qzUGme8JaoRQ@mail.gmail.com>
Message-ID: <CAHYVw0yRvTE9_Hf80qqkJozeRXDX0nLQBo--jqJ5Z8-Bs7YGFA@mail.gmail.com>

Show me the efficient simd code in the gmp  c code base first :)

On Sunday, June 19, 2016, David Feuer <david.feuer at gmail.com> wrote:

> How does that excuse an inefficient implementation of Bits Integer?
> On Jun 19, 2016 6:58 PM, "Carter Schonwald" <carter.schonwald at gmail.com
> <javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>> wrote:
>
>> Did you read the code for the underlying gmp c code? And associated c
>> APIs?
>>
>> I'm told that part of the value of the new style gmp binding is that it
>> should be safer to link to any missing gmp functionality you may wish to
>> use.
>>
>> On Sunday, June 19, 2016, Henning Thielemann <
>> lemming at henning-thielemann.de
>> <javascript:_e(%7B%7D,'cvml','lemming at henning-thielemann.de');>> wrote:
>>
>>>
>>> On Sun, 19 Jun 2016, David Feuer wrote:
>>>
>>> Your quick look is insufficient. There are custom implementations of bit
>>>> setting and clearing operations that use GMP primitives instead of the
>>>> Data.Bits defaults.
>>>>
>>>
>>> I have seen them, but the expensive operations like 'union' and
>>> 'difference' are not optimized, right? They would benefit from CPU vector
>>> instructions.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160619/f66e1ff1/attachment.html>

From wren at community.haskell.org  Mon Jun 20 23:29:17 2016
From: wren at community.haskell.org (wren romano)
Date: Mon, 20 Jun 2016 19:29:17 -0400
Subject: Proposal: add ReadPrec-based functions to Read1/Read2
In-Reply-To: <CAHYVw0zWNTs8OpUaS7uGoWX899gqGtO1qr+Y6Gsn=U7=fgdZ8A@mail.gmail.com>
References: <CADdQpRAcdCyq9KkChg4StBJ026jxrKSfyQbfPv8PQ1euDKEQtA@mail.gmail.com>
 <CAHYVw0zWNTs8OpUaS7uGoWX899gqGtO1qr+Y6Gsn=U7=fgdZ8A@mail.gmail.com>
Message-ID: <CABUjdS5rn878xB6JJfrXD-7As6R3KOxy4qkC6uebgySaAX9z_g@mail.gmail.com>

On Sun, Jun 19, 2016 at 6:56 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> I'm always in favor of providing algorithmicly better interfaces, so barring
> me learning that there's doe thing even better we should do , +1 :)

+1.

-- 
Live well,
~wren

From tanuki at gmail.com  Tue Jun 21 00:12:50 2016
From: tanuki at gmail.com (Theodore Lief Gannon)
Date: Mon, 20 Jun 2016 17:12:50 -0700
Subject: Proposal: add ReadPrec-based functions to Read1/Read2
In-Reply-To: <CABUjdS5rn878xB6JJfrXD-7As6R3KOxy4qkC6uebgySaAX9z_g@mail.gmail.com>
References: <CADdQpRAcdCyq9KkChg4StBJ026jxrKSfyQbfPv8PQ1euDKEQtA@mail.gmail.com>
 <CAHYVw0zWNTs8OpUaS7uGoWX899gqGtO1qr+Y6Gsn=U7=fgdZ8A@mail.gmail.com>
 <CABUjdS5rn878xB6JJfrXD-7As6R3KOxy4qkC6uebgySaAX9z_g@mail.gmail.com>
Message-ID: <CAJoPsuChu+tdvU9qcHgcGmj1fA7uAQOJiZiCR+RLjKQ5AGe4hQ@mail.gmail.com>

I suppose I should eventually step and start voting on proposals instead of
just observing the process... so +1 as well.

On Mon, Jun 20, 2016 at 4:29 PM, wren romano <wren at community.haskell.org>
wrote:

> On Sun, Jun 19, 2016 at 6:56 PM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
> > I'm always in favor of providing algorithmicly better interfaces, so
> barring
> > me learning that there's doe thing even better we should do , +1 :)
>
> +1.
>
> --
> Live well,
> ~wren
> _______________________________________________
> 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/20160620/ab456264/attachment.html>

From david.feuer at gmail.com  Wed Jun 22 16:58:17 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 22 Jun 2016 12:58:17 -0400
Subject: How bad would it be for containers to depend on transformers?
Message-ID: <CAMgWh9u18wcAMm7VKkqzn7fVrBTWGxNvtPDLsPiMUV7qzfBAsw@mail.gmail.com>

Currently, containers does not depend on transformers, so it has to
duplicate its functionality or just do without. Since transformers is also
a GHC boot package, I believe it should be feasible to make containers
depend on it. To what extent would that reduce
parallelizability of GHC builds or otherwise make people mad?

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160622/cf18f78f/attachment.html>

From david.feuer at gmail.com  Wed Jun 22 17:01:57 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 22 Jun 2016 13:01:57 -0400
Subject: User-friendly access to SmallArray# and SmallMutableArray#
Message-ID: <CAMgWh9vOhy2QDjQQ6q+nGVo0yK2RDVfjHoRXq-TM+eZ1DFNmuA@mail.gmail.com>

The only user-friendly wrappers I can find for SmallArray# and
SmallMutableArray# are in Data.Discrimination.Internal.SmallArray in the
discrimination package. What are the chances that we could get something
like that in the array package, or possibly some other GHC boot package? I
can't use discrimination in containers!

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160622/7e8ed560/attachment.html>

From ekmett at gmail.com  Wed Jun 22 18:24:36 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 22 Jun 2016 14:24:36 -0400
Subject: How bad would it be for containers to depend on transformers?
In-Reply-To: <CAMgWh9u18wcAMm7VKkqzn7fVrBTWGxNvtPDLsPiMUV7qzfBAsw@mail.gmail.com>
References: <CAMgWh9u18wcAMm7VKkqzn7fVrBTWGxNvtPDLsPiMUV7qzfBAsw@mail.gmail.com>
Message-ID: <20255157-DABF-4450-A71D-398ABE61AB5F@gmail.com>

If we're just talking about building one or two transformers then I'd say we should avoid incurring the dependency. The outcry would far far outweigh the code sharing advantage for one or two types. E.g. base duplicates State internally for mapAccumL for instance for this sort of reason.

Sent from my iPad

> On Jun 22, 2016, at 12:58 PM, David Feuer <david.feuer at gmail.com> wrote:
> 
> Currently, containers does not depend on transformers, so it has to duplicate its functionality or just do without. Since transformers is also a GHC boot package, I believe it should be feasible to make containers depend on it. To what extent would that reduce 
> parallelizability of GHC builds or otherwise make people mad?
> 
> David
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From ekmett at gmail.com  Thu Jun 23 00:58:46 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 22 Jun 2016 20:58:46 -0400
Subject: User-friendly access to SmallArray# and SmallMutableArray#
In-Reply-To: <CAMgWh9vOhy2QDjQQ6q+nGVo0yK2RDVfjHoRXq-TM+eZ1DFNmuA@mail.gmail.com>
References: <CAMgWh9vOhy2QDjQQ6q+nGVo0yK2RDVfjHoRXq-TM+eZ1DFNmuA@mail.gmail.com>
Message-ID: <CAJumaK92wekAQ=4=iU9SV9PNvSCXn6B99ttaOdXY15cF250C=w@mail.gmail.com>

I've been talking to Dan Doel about adding them to `primitive`, possibly w/
backwards compatibility wrappers.

On Wed, Jun 22, 2016 at 1:01 PM, David Feuer <david.feuer at gmail.com> wrote:

> The only user-friendly wrappers I can find for SmallArray# and
> SmallMutableArray# are in Data.Discrimination.Internal.SmallArray in the
> discrimination package. What are the chances that we could get something
> like that in the array package, or possibly some other GHC boot package? I
> can't use discrimination in containers!
>
> David
>
> _______________________________________________
> 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/20160622/4139aa98/attachment.html>

From david.feuer at gmail.com  Thu Jun 23 01:07:03 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 22 Jun 2016 21:07:03 -0400
Subject: User-friendly access to SmallArray# and SmallMutableArray#
In-Reply-To: <CAJumaK92wekAQ=4=iU9SV9PNvSCXn6B99ttaOdXY15cF250C=w@mail.gmail.com>
References: <CAMgWh9vOhy2QDjQQ6q+nGVo0yK2RDVfjHoRXq-TM+eZ1DFNmuA@mail.gmail.com>
 <CAJumaK92wekAQ=4=iU9SV9PNvSCXn6B99ttaOdXY15cF250C=w@mail.gmail.com>
Message-ID: <CAMgWh9v8Cxyi6ZqSWQ=1YOiHvPf+nRC_TvuQFezUa3x2a2wXSA@mail.gmail.com>

That's great, but primitive is not a GHC boot library, and it depends on
transformers, ..., so I'm still stuck copying code into containers (the
copy I made from discrimination falls back to MutableArray#).
On Jun 22, 2016 8:58 PM, "Edward Kmett" <ekmett at gmail.com> wrote:

> I've been talking to Dan Doel about adding them to `primitive`, possibly
> w/ backwards compatibility wrappers.
>
> On Wed, Jun 22, 2016 at 1:01 PM, David Feuer <david.feuer at gmail.com>
> wrote:
>
>> The only user-friendly wrappers I can find for SmallArray# and
>> SmallMutableArray# are in Data.Discrimination.Internal.SmallArray in the
>> discrimination package. What are the chances that we could get something
>> like that in the array package, or possibly some other GHC boot package? I
>> can't use discrimination in containers!
>>
>> David
>>
>> _______________________________________________
>> 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/20160622/4da91291/attachment.html>

From wren at community.haskell.org  Sun Jun 26 01:46:19 2016
From: wren at community.haskell.org (wren romano)
Date: Sat, 25 Jun 2016 21:46:19 -0400
Subject: User-friendly access to SmallArray# and SmallMutableArray#
In-Reply-To: <CAMgWh9vOhy2QDjQQ6q+nGVo0yK2RDVfjHoRXq-TM+eZ1DFNmuA@mail.gmail.com>
References: <CAMgWh9vOhy2QDjQQ6q+nGVo0yK2RDVfjHoRXq-TM+eZ1DFNmuA@mail.gmail.com>
Message-ID: <CABUjdS7y2+YyHUNYs3YdeDXWQZrMPF5PfTQrCSfub++Z+grg8w@mail.gmail.com>

On Wed, Jun 22, 2016 at 1:01 PM, David Feuer <david.feuer at gmail.com> wrote:
> The only user-friendly wrappers I can find for SmallArray# and
> SmallMutableArray# are in Data.Discrimination.Internal.SmallArray in the
> discrimination package. What are the chances that we could get something
> like that in the array package, or possibly some other GHC boot package? I
> can't use discrimination in containers!

Depending on what you have in mind, I do have some (relatively)
user-friendly wrappers in the unreleased new version of
bytestring-trie. I mention because I'm planning on moving those
wrappers into containers (and making them public so bytestirng-trie
can reused them) once I get a chance to add the AMT implementation for
IntMap this autumn.

-- 
Live well,
~wren

From ekmett at gmail.com  Mon Jun 27 16:12:36 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 27 Jun 2016 12:12:36 -0400
Subject: User-friendly access to SmallArray# and SmallMutableArray#
In-Reply-To: <CABUjdS7y2+YyHUNYs3YdeDXWQZrMPF5PfTQrCSfub++Z+grg8w@mail.gmail.com>
References: <CAMgWh9vOhy2QDjQQ6q+nGVo0yK2RDVfjHoRXq-TM+eZ1DFNmuA@mail.gmail.com>
 <CABUjdS7y2+YyHUNYs3YdeDXWQZrMPF5PfTQrCSfub++Z+grg8w@mail.gmail.com>
Message-ID: <CAJumaK-B+3G+XvrfYG+tzXe8hKDi63q8p4_L7fuXapdQVbZy0Q@mail.gmail.com>

>From a core libraries perspective it'd be good to have these in one place.
Right now we have them in primitive.

If we're going to start duplicating *that* much code, it seems it'd be
worth incurring the dependency, which would get David his transformers
dependency in turn.

-Edward

On Sat, Jun 25, 2016 at 9:46 PM, wren romano <wren at community.haskell.org>
wrote:

> On Wed, Jun 22, 2016 at 1:01 PM, David Feuer <david.feuer at gmail.com>
> wrote:
> > The only user-friendly wrappers I can find for SmallArray# and
> > SmallMutableArray# are in Data.Discrimination.Internal.SmallArray in the
> > discrimination package. What are the chances that we could get something
> > like that in the array package, or possibly some other GHC boot package?
> I
> > can't use discrimination in containers!
>
> Depending on what you have in mind, I do have some (relatively)
> user-friendly wrappers in the unreleased new version of
> bytestring-trie. I mention because I'm planning on moving those
> wrappers into containers (and making them public so bytestirng-trie
> can reused them) once I get a chance to add the AMT implementation for
> IntMap this autumn.
>
> --
> Live well,
> ~wren
> _______________________________________________
> 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/20160627/79c96f3f/attachment.html>

From nicolas.godbout at gmail.com  Mon Jun 27 21:45:29 2016
From: nicolas.godbout at gmail.com (Nicolas Godbout)
Date: Mon, 27 Jun 2016 17:45:29 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
Message-ID: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>


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.


From david.feuer at gmail.com  Mon Jun 27 21:47:20 2016
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 27 Jun 2016 17:47:20 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
Message-ID: <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>

+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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160627/4e46e06c/attachment.html>

From nicolas.godbout at gmail.com  Mon Jun 27 21:52:21 2016
From: nicolas.godbout at gmail.com (Nicolas Godbout)
Date: Mon, 27 Jun 2016 17:52:21 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
Message-ID: <492E7850-DD23-4850-B48D-461E1EA65281@gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160627/3c575f3d/attachment.html>

From david.feuer at gmail.com  Mon Jun 27 21:56:44 2016
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 27 Jun 2016 17:56:44 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <492E7850-DD23-4850-B48D-461E1EA65281@gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <492E7850-DD23-4850-B48D-461E1EA65281@gmail.com>
Message-ID: <CAMgWh9tcrLK5daNtvQcBGwsGi2O26V9X9W=qdzYno3t42e1QKA@mail.gmail.com>

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" <nicolas.godbout at gmail.com>
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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160627/7eea4a23/attachment.html>

From david.feuer at gmail.com  Mon Jun 27 22:17:34 2016
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 27 Jun 2016 18:17:34 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAMgWh9tcrLK5daNtvQcBGwsGi2O26V9X9W=qdzYno3t42e1QKA@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <492E7850-DD23-4850-B48D-461E1EA65281@gmail.com>
 <CAMgWh9tcrLK5daNtvQcBGwsGi2O26V9X9W=qdzYno3t42e1QKA@mail.gmail.com>
Message-ID: <CAMgWh9t+w13oCwHN=mybzCZyBnmC0zUGh1Ssa8Z1sHUqQZearA@mail.gmail.com>

Another option might be "find".
On Jun 27, 2016 5:56 PM, "David Feuer" <david.feuer at gmail.com> 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" <nicolas.godbout at gmail.com>
> 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160627/0f584686/attachment-0001.html>

From malcolm.wallace at me.com  Tue Jun 28 05:14:15 2016
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Tue, 28 Jun 2016 06:14:15 +0100
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAMgWh9t+w13oCwHN=mybzCZyBnmC0zUGh1Ssa8Z1sHUqQZearA@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <492E7850-DD23-4850-B48D-461E1EA65281@gmail.com>
 <CAMgWh9tcrLK5daNtvQcBGwsGi2O26V9X9W=qdzYno3t42e1QKA@mail.gmail.com>
 <CAMgWh9t+w13oCwHN=mybzCZyBnmC0zUGh1Ssa8Z1sHUqQZearA@mail.gmail.com>
Message-ID: <7A1CFFA0-FFBC-4E97-A749-AC480276C625@me.com>

Or "lookupSharedPointer", if that is the important part of the operational semantics.

 Regards,
    Malcolm (iPhone)

On 27 Jun 2016, at 23:17, David Feuer <david.feuer at gmail.com> wrote:

Another option might be "find".

> On Jun 27, 2016 5:56 PM, "David Feuer" <david.feuer at gmail.com> 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" <nicolas.godbout at gmail.com> 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
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/20160628/9a62b5b8/attachment.html>

From mail at joachim-breitner.de  Tue Jun 28 08:46:54 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 28 Jun 2016 10:46:54 +0200
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <7A1CFFA0-FFBC-4E97-A749-AC480276C625@me.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <492E7850-DD23-4850-B48D-461E1EA65281@gmail.com>
 <CAMgWh9tcrLK5daNtvQcBGwsGi2O26V9X9W=qdzYno3t42e1QKA@mail.gmail.com>
 <CAMgWh9t+w13oCwHN=mybzCZyBnmC0zUGh1Ssa8Z1sHUqQZearA@mail.gmail.com>
 <7A1CFFA0-FFBC-4E97-A749-AC480276C625@me.com>
Message-ID: <1467103614.1599.23.camel@joachim-breitner.de>

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 <david.feuer at gmail.com> wrote:
> 
> Another option might be "find".
> On Jun 27, 2016 5:56 PM, "David Feuer" <david.feuer at gmail.com> 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" <nicolas.godbout at gmail.c
> > 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
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160628/661454a5/attachment.sig>

From lemming at henning-thielemann.de  Tue Jun 28 09:19:16 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 28 Jun 2016 11:19:16 +0200 (CEST)
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
Message-ID: <alpine.DEB.2.02.1606281050020.8716@sputnik>


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

From lambda.fairy at gmail.com  Tue Jun 28 09:22:59 2016
From: lambda.fairy at gmail.com (Chris Wong)
Date: Tue, 28 Jun 2016 21:22:59 +1200
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
Message-ID: <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>

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

From ollie at ocharles.org.uk  Tue Jun 28 09:44:59 2016
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Tue, 28 Jun 2016 09:44:59 +0000
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
Message-ID: <CAGRp5R=tUehAirkNks_gSnwK0C=a=6Hu-n4vqTiRB3_obmMVYw@mail.gmail.com>

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, <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160628/a3c64849/attachment-0001.html>

From andreas.abel at ifi.lmu.de  Tue Jun 28 09:53:55 2016
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Tue, 28 Jun 2016 11:53:55 +0200
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAGRp5R=tUehAirkNks_gSnwK0C=a=6Hu-n4vqTiRB3_obmMVYw@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
 <CAGRp5R=tUehAirkNks_gSnwK0C=a=6Hu-n4vqTiRB3_obmMVYw@mail.gmail.com>
Message-ID: <57724933.4050508@ifi.lmu.de>

+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, <lambda.fairy at gmail.com
> <mailto: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
>     <mailto: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 <mailto: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 <mailto:Libraries at haskell.org>
>      >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>      >
>      >
>      > _______________________________________________
>      > Libraries mailing list
>      > Libraries at haskell.org <mailto: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 <mailto: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
>


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

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

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From michael at snoyman.com  Tue Jun 28 09:58:59 2016
From: michael at snoyman.com (Michael Snoyman)
Date: Tue, 28 Jun 2016 12:58:59 +0300
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <57724933.4050508@ifi.lmu.de>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
 <CAGRp5R=tUehAirkNks_gSnwK0C=a=6Hu-n4vqTiRB3_obmMVYw@mail.gmail.com>
 <57724933.4050508@ifi.lmu.de>
Message-ID: <CAKA2JgKPNjHvbd1tSap2h82Jaom+LahnwOFs8HXgfv7g1kFdJA@mail.gmail.com>

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 <andreas.abel at ifi.lmu.de>
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, <lambda.fairy at gmail.com
>> <mailto: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
>>     <mailto: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 <mailto: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 <mailto:Libraries at haskell.org>
>>      >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>      >
>>      >
>>      > _______________________________________________
>>      > Libraries mailing list
>>      > Libraries at haskell.org <mailto: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 <mailto: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
>>
>>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> andreas.abel at gu.se
> http://www2.tcs.ifi.lmu.de/~abel/
>
> _______________________________________________
> 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/20160628/683cd07d/attachment.html>

From spam at scientician.net  Tue Jun 28 10:20:36 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 28 Jun 2016 12:20:36 +0200
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAGRp5R=tUehAirkNks_gSnwK0C=a=6Hu-n4vqTiRB3_obmMVYw@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
 <CAGRp5R=tUehAirkNks_gSnwK0C=a=6Hu-n4vqTiRB3_obmMVYw@mail.gmail.com>
Message-ID: <nktj1k$b4t$1@ger.gmane.org>

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



From dct25-561bs at mythic-beasts.com  Tue Jun 28 16:38:17 2016
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Tue, 28 Jun 2016 17:38:17 +0100
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
Message-ID: <CAErCyQ9dtCxgBvyF_eR5b_rP+uAxWmMdK+Xkh9OYczFnHqKgmw@mail.gmail.com>

+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
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/20160628/5063bc21/attachment.html>

From david.feuer at gmail.com  Wed Jun 29 06:12:47 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 29 Jun 2016 02:12:47 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAErCyQ9dtCxgBvyF_eR5b_rP+uAxWmMdK+Xkh9OYczFnHqKgmw@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAErCyQ9dtCxgBvyF_eR5b_rP+uAxWmMdK+Xkh9OYczFnHqKgmw@mail.gmail.com>
Message-ID: <CAMgWh9tU9kVoAv_ZqgD-yXj5PaaAiCa1bunML3u9qwoAxsNyHg@mail.gmail.com>

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
<dct25-561bs at mythic-beasts.com> 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
> 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
>

From mail at joachim-breitner.de  Wed Jun 29 08:18:06 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 29 Jun 2016 10:18:06 +0200
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAMgWh9tU9kVoAv_ZqgD-yXj5PaaAiCa1bunML3u9qwoAxsNyHg@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAErCyQ9dtCxgBvyF_eR5b_rP+uAxWmMdK+Xkh9OYczFnHqKgmw@mail.gmail.com>
 <CAMgWh9tU9kVoAv_ZqgD-yXj5PaaAiCa1bunML3u9qwoAxsNyHg@mail.gmail.com>
Message-ID: <1467188286.1633.7.camel@joachim-breitner.de>

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
> <dct25-561bs at mythic-beasts.com> 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
> > 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
-- 

Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160629/65c04d54/attachment.sig>

From ekmett at gmail.com  Wed Jun 29 09:17:25 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 29 Jun 2016 05:17:25 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <1467188286.1633.7.camel@joachim-breitner.de>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAErCyQ9dtCxgBvyF_eR5b_rP+uAxWmMdK+Xkh9OYczFnHqKgmw@mail.gmail.com>
 <CAMgWh9tU9kVoAv_ZqgD-yXj5PaaAiCa1bunML3u9qwoAxsNyHg@mail.gmail.com>
 <1467188286.1633.7.camel@joachim-breitner.de>
Message-ID: <CAJumaK_3bJ0GfrV2NfKKZeG3rUB1ZSgO7CJopB4zyUm=7wWSJw@mail.gmail.com>

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 <mail at joachim-breitner.de>
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
> > <dct25-561bs at mythic-beasts.com> 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
> > > 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
> --
>
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> 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/f8549aac/attachment-0001.html>

From andreas.abel at ifi.lmu.de  Wed Jun 29 12:36:23 2016
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Wed, 29 Jun 2016 14:36:23 +0200
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAJumaK_3bJ0GfrV2NfKKZeG3rUB1ZSgO7CJopB4zyUm=7wWSJw@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAErCyQ9dtCxgBvyF_eR5b_rP+uAxWmMdK+Xkh9OYczFnHqKgmw@mail.gmail.com>
 <CAMgWh9tU9kVoAv_ZqgD-yXj5PaaAiCa1bunML3u9qwoAxsNyHg@mail.gmail.com>
 <1467188286.1633.7.camel@joachim-breitner.de>
 <CAJumaK_3bJ0GfrV2NfKKZeG3rUB1ZSgO7CJopB4zyUm=7wWSJw@mail.gmail.com>
Message-ID: <5773C0C7.8040602@ifi.lmu.de>

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
> <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> 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
>      > <dct25-561bs at mythic-beasts.com
>     <mailto:dct25-561bs at mythic-beasts.com>> 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
>      > > Libraries at haskell.org <mailto:Libraries at haskell.org>
>      > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>      > >
>      > > _______________________________________________
>      > > Libraries mailing list
>      > > Libraries at haskell.org <mailto:Libraries at haskell.org>
>      > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>      > >
>      > _______________________________________________
>      > Libraries mailing list
>      > Libraries at haskell.org <mailto:Libraries at haskell.org>
>      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>     --
>
>     Joachim “nomeata” Breitner
>     mail at joachim-breitner.de <mailto:mail at joachim-breitner.de> •
>     https://www.joachim-breitner.de/
>        XMPP: nomeata at joachim-breitner.de
>     <mailto:nomeata at joachim-breitner.de> • OpenPGP-Key: 0xF0FBF51F
>        Debian Developer: nomeata at debian.org <mailto:nomeata at debian.org>
>
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto: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
>


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

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

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From david.feuer at gmail.com  Wed Jun 29 14:35:41 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 29 Jun 2016 10:35:41 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAJumaK_3bJ0GfrV2NfKKZeG3rUB1ZSgO7CJopB4zyUm=7wWSJw@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAErCyQ9dtCxgBvyF_eR5b_rP+uAxWmMdK+Xkh9OYczFnHqKgmw@mail.gmail.com>
 <CAMgWh9tU9kVoAv_ZqgD-yXj5PaaAiCa1bunML3u9qwoAxsNyHg@mail.gmail.com>
 <1467188286.1633.7.camel@joachim-breitner.de>
 <CAJumaK_3bJ0GfrV2NfKKZeG3rUB1ZSgO7CJopB4zyUm=7wWSJw@mail.gmail.com>
Message-ID: <CAMgWh9sb7wX9RkT14C5HhxETo2Q4JZxxGb=K97nfSBmKSfuuvQ@mail.gmail.com>

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" <ekmett at gmail.com> 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 <
> mail at joachim-breitner.de> 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
>> > <dct25-561bs at mythic-beasts.com> 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
>> > > 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
>> --
>>
>> Joachim “nomeata” Breitner
>>   mail at joachim-breitner.de • https://www.joachim-breitner.de/
>>   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>>   Debian Developer: nomeata at debian.org
>>
>> _______________________________________________
>> 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/32393957/attachment.html>

From david.feuer at gmail.com  Wed Jun 29 17:39:47 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 29 Jun 2016 13:39:47 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <5773C0C7.8040602@ifi.lmu.de>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAErCyQ9dtCxgBvyF_eR5b_rP+uAxWmMdK+Xkh9OYczFnHqKgmw@mail.gmail.com>
 <CAMgWh9tU9kVoAv_ZqgD-yXj5PaaAiCa1bunML3u9qwoAxsNyHg@mail.gmail.com>
 <1467188286.1633.7.camel@joachim-breitner.de>
 <CAJumaK_3bJ0GfrV2NfKKZeG3rUB1ZSgO7CJopB4zyUm=7wWSJw@mail.gmail.com>
 <5773C0C7.8040602@ifi.lmu.de>
Message-ID: <CAMgWh9tbQALkBDAR676daoDStHwYE3etyWu4=AxvqqzcrsrhnA@mail.gmail.com>

+1 for lookupEntry. I think that's very intuitive.

On Wed, Jun 29, 2016 at 8:36 AM, Andreas Abel <andreas.abel at ifi.lmu.de> 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
>> <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> 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
>>      > <dct25-561bs at mythic-beasts.com
>>     <mailto:dct25-561bs at mythic-beasts.com>> 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
>>      > > Libraries at haskell.org <mailto:Libraries at haskell.org>
>>      > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>      > >
>>      > > _______________________________________________
>>      > > Libraries mailing list
>>      > > Libraries at haskell.org <mailto:Libraries at haskell.org>
>>      > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>      > >
>>      > _______________________________________________
>>      > Libraries mailing list
>>      > Libraries at haskell.org <mailto:Libraries at haskell.org>
>>      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>     --
>>
>>     Joachim “nomeata” Breitner
>>     mail at joachim-breitner.de <mailto:mail at joachim-breitner.de> •
>>     https://www.joachim-breitner.de/
>>        XMPP: nomeata at joachim-breitner.de
>>     <mailto:nomeata at joachim-breitner.de> • OpenPGP-Key: 0xF0FBF51F
>>        Debian Developer: nomeata at debian.org <mailto:nomeata at debian.org>
>>
>>     _______________________________________________
>>     Libraries mailing list
>>     Libraries at haskell.org <mailto: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
>>
>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> andreas.abel at gu.se
> http://www2.tcs.ifi.lmu.de/~abel/
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From davidleothomas at gmail.com  Wed Jun 29 20:57:36 2016
From: davidleothomas at gmail.com (David Thomas)
Date: Wed, 29 Jun 2016 13:57:36 -0700
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
Message-ID: <CAJUDvciCEiUOBAHSwYq6BtNkFo5BXVVJKQDvdRj5mVPihwh61Q@mail.gmail.com>

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

From david.feuer at gmail.com  Wed Jun 29 21:02:00 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 29 Jun 2016 17:02:00 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAJUDvciCEiUOBAHSwYq6BtNkFo5BXVVJKQDvdRj5mVPihwh61Q@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
 <CAJUDvciCEiUOBAHSwYq6BtNkFo5BXVVJKQDvdRj5mVPihwh61Q@mail.gmail.com>
Message-ID: <CAMgWh9vJLGT87oFeAxpM4Ka0mDQVgvvh6qvL+ukFC8rSscJnAg@mail.gmail.com>

I suspect we may want both functions.

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

From alec at deviant-logic.net  Wed Jun 29 21:12:08 2016
From: alec at deviant-logic.net (Alec)
Date: Wed, 29 Jun 2016 21:12:08 +0000
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAJUDvciCEiUOBAHSwYq6BtNkFo5BXVVJKQDvdRj5mVPihwh61Q@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
 <CAJUDvciCEiUOBAHSwYq6BtNkFo5BXVVJKQDvdRj5mVPihwh61Q@mail.gmail.com>
Message-ID: <CA+0GNnB_YyuSh+643sC20_VmsVGbo855RuOuJYCXvzfjs-O8cQ@mail.gmail.com>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160629/d7939e7c/attachment.html>

From david.feuer at gmail.com  Wed Jun 29 21:18:20 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 29 Jun 2016 17:18:20 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CA+0GNnB_YyuSh+643sC20_VmsVGbo855RuOuJYCXvzfjs-O8cQ@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
 <CAJUDvciCEiUOBAHSwYq6BtNkFo5BXVVJKQDvdRj5mVPihwh61Q@mail.gmail.com>
 <CA+0GNnB_YyuSh+643sC20_VmsVGbo855RuOuJYCXvzfjs-O8cQ@mail.gmail.com>
Message-ID: <CAMgWh9vPtzkGM1ZDBF1Jt8xnyVF3b0z-VnH2JNbShhVys0QA8g@mail.gmail.com>

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/12105956/attachment-0001.html>

From alec at deviant-logic.net  Wed Jun 29 21:48:50 2016
From: alec at deviant-logic.net (Alec)
Date: Wed, 29 Jun 2016 21:48:50 +0000
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAMgWh9vPtzkGM1ZDBF1Jt8xnyVF3b0z-VnH2JNbShhVys0QA8g@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
 <CAJUDvciCEiUOBAHSwYq6BtNkFo5BXVVJKQDvdRj5mVPihwh61Q@mail.gmail.com>
 <CA+0GNnB_YyuSh+643sC20_VmsVGbo855RuOuJYCXvzfjs-O8cQ@mail.gmail.com>
 <CAMgWh9vPtzkGM1ZDBF1Jt8xnyVF3b0z-VnH2JNbShhVys0QA8g@mail.gmail.com>
Message-ID: <CA+0GNnAnRqaiEEJN0U+nrZcM6VXj5jkHCTWO+HYxngTfYiM=zQ@mail.gmail.com>

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

From spam at scientician.net  Wed Jun 29 22:06:12 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Thu, 30 Jun 2016 00:06:12 +0200
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CA+0GNnAnRqaiEEJN0U+nrZcM6VXj5jkHCTWO+HYxngTfYiM=zQ@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
 <CAJUDvciCEiUOBAHSwYq6BtNkFo5BXVVJKQDvdRj5mVPihwh61Q@mail.gmail.com>
 <CA+0GNnB_YyuSh+643sC20_VmsVGbo855RuOuJYCXvzfjs-O8cQ@mail.gmail.com>
 <CAMgWh9vPtzkGM1ZDBF1Jt8xnyVF3b0z-VnH2JNbShhVys0QA8g@mail.gmail.com>
 <CA+0GNnAnRqaiEEJN0U+nrZcM6VXj5jkHCTWO+HYxngTfYiM=zQ@mail.gmail.com>
Message-ID: <nl1gok$hf8$1@ger.gmane.org>

On 06/29/2016 11:48 PM, Alec wrote:
> `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}
> 

"I love bikesheds! Don't you!?" :)

I can only agree that it's a little incongrouous... but I'll defer to
maintainer's privilege in the interest of getting things done :).

Regards,


From david.feuer at gmail.com  Wed Jun 29 22:16:18 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 29 Jun 2016 18:16:18 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <nl1gok$hf8$1@ger.gmane.org>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
 <CAJUDvciCEiUOBAHSwYq6BtNkFo5BXVVJKQDvdRj5mVPihwh61Q@mail.gmail.com>
 <CA+0GNnB_YyuSh+643sC20_VmsVGbo855RuOuJYCXvzfjs-O8cQ@mail.gmail.com>
 <CAMgWh9vPtzkGM1ZDBF1Jt8xnyVF3b0z-VnH2JNbShhVys0QA8g@mail.gmail.com>
 <CA+0GNnAnRqaiEEJN0U+nrZcM6VXj5jkHCTWO+HYxngTfYiM=zQ@mail.gmail.com>
 <nl1gok$hf8$1@ger.gmane.org>
Message-ID: <CAMgWh9tsBDqcWxWXBaaQ12TcL3ywDgL_0WYaMk6wZsvPBEWy1A@mail.gmail.com>

Paint it what you like. Just not `lookup` :-).

On Wed, Jun 29, 2016 at 6:06 PM, Bardur Arantsson <spam at scientician.net> wrote:
> On 06/29/2016 11:48 PM, Alec wrote:
>> `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}
>>
>
> "I love bikesheds! Don't you!?" :)
>
> I can only agree that it's a little incongrouous... but I'll defer to
> maintainer's privilege in the interest of getting things done :).
>
> Regards,
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From david.feuer at gmail.com  Wed Jun 29 22:48:46 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 29 Jun 2016 18:48:46 -0400
Subject: Notification: adding adjust' to Data.Sequence (rage on!)
In-Reply-To: <CAMgWh9uc7RSCtafSCnTGOK3_oJHvKzbzGF2EmvXtmjYzaxO6zQ@mail.gmail.com>
References: <CAMgWh9sidco2147LpFbkFsqGDaRvpQ=Fh9LjMZV=sLn5jzuOJg@mail.gmail.com>
 <CAMgWh9sJ5zx-ZxcAkZBcomyBgNFcswz-Mi29Lg92Cp=7QU5New@mail.gmail.com>
 <CAMgWh9ufV2WvzKPeGM6P83KHL_kQNva9sbgQRvsf71kcxmHDiw@mail.gmail.com>
 <CAMgWh9sUt=_fj22jRf0qS_=35mR66fgmGrRhyDwOg1TBXcp_dQ@mail.gmail.com>
 <CAMgWh9sD3eWB6XtPLS0NORetRKYZaO+H0O=nDfnjU2CWjkCfkA@mail.gmail.com>
 <CAMgWh9s1GSc2ecGz0uV4wPWeM8vwCB0botv3pGFJNe3jaTeoag@mail.gmail.com>
 <CAMgWh9uZ_KciZovt970xt-xp8hCGY2PGoUC1oC4=tcxKtnfBuw@mail.gmail.com>
 <CAMgWh9u56fJezaTXnYvPjkHMTdoMvfFrMmMqU33o2c6sK2fqjw@mail.gmail.com>
 <CAMgWh9tVtnbZARwXc+9LWFFRfcVmfkeLYTkkL4WUSPw7EAwa6g@mail.gmail.com>
 <CAMgWh9ufJ5_NcCe4Ktfow+GV_eUBz4JOEQS4uNr1bCr_AM0zRg@mail.gmail.com>
 <CAMgWh9vSnKnt3=XcKz-J9n4TckVPE=EgGven+mHpQhmGtsGiRg@mail.gmail.com>
 <CAMgWh9uc7RSCtafSCnTGOK3_oJHvKzbzGF2EmvXtmjYzaxO6zQ@mail.gmail.com>
Message-ID: <CAMgWh9tOf-_fo2N4wLADpWYth2aoRHiHEWtsQzHuPDe_sgqAMA@mail.gmail.com>

This is not a proposal. I know that for reasons I don't know, the decision
was made to move extra-strict functions for the other containers into
separate .Strict modules. I greatly dislike the result of that decision
(both from the API standpoint and especially from a maintenance
standpoint), but I'm not arguing to change that.

However, I am adding an extra-strict function to Data.Sequence, with the
following non-negotiable semantics:

adjust' f i xs =
  case xs !? i of
    Nothing -> xs
    Just x -> let !x' = f x in update i x' xs

This will provide an efficient way to adjust a sequence element without
risking thunk chains and memory leaks.

I'm sure some people will be angry. I just wanted to make sure no one says
I snuck this in behind their back.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160629/617b23fb/attachment-0001.html>

From wren at community.haskell.org  Thu Jun 30 19:26:14 2016
From: wren at community.haskell.org (wren romano)
Date: Thu, 30 Jun 2016 15:26:14 -0400
Subject: Proposal for containers: Add 'lookup' function to Data.Set
In-Reply-To: <CAMgWh9tsBDqcWxWXBaaQ12TcL3ywDgL_0WYaMk6wZsvPBEWy1A@mail.gmail.com>
References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com>
 <CAMgWh9tOcHuk6C4vdpTX9bsDT-yC77ObaGWuV8__554LB0Xspg@mail.gmail.com>
 <CANQO64KjWD8rkMqQnsbGA3iwR4+VsTM+J93X_BbXqeGY9BZFVQ@mail.gmail.com>
 <CAJUDvciCEiUOBAHSwYq6BtNkFo5BXVVJKQDvdRj5mVPihwh61Q@mail.gmail.com>
 <CA+0GNnB_YyuSh+643sC20_VmsVGbo855RuOuJYCXvzfjs-O8cQ@mail.gmail.com>
 <CAMgWh9vPtzkGM1ZDBF1Jt8xnyVF3b0z-VnH2JNbShhVys0QA8g@mail.gmail.com>
 <CA+0GNnAnRqaiEEJN0U+nrZcM6VXj5jkHCTWO+HYxngTfYiM=zQ@mail.gmail.com>
 <nl1gok$hf8$1@ger.gmane.org>
 <CAMgWh9tsBDqcWxWXBaaQ12TcL3ywDgL_0WYaMk6wZsvPBEWy1A@mail.gmail.com>
Message-ID: <CABUjdS7MR+uzLgg6xUjurE1C_XofjwvJw_364o+f5eJ7HRw3=A@mail.gmail.com>

FWIW, as someone who often interns strings in her programs, I'd
suggest *not* naming it "intern" (or variations thereon). One issue is
the "and store it if it's not there yet" issue already mentioned. But
another —and imo more important— issue is that one of the main goals
of interning things is so that you can get a fast equality check. In
general whenever we intern things we're going to return some token,
which supports fast equality, and takes up as little memory as
possible, but which can later on be cashed in for the original
(shared) value if we actually need it. In impure languages we can use
the pointer to the object as our token, but we can't do that (without
serious grossness) in Haskell so we'd return some other token like an
integer, perhaps with a newtype wrapper to keep track of its
providence so we can avoid mixing up tokens from different intern
tables.

I already have an implementation of intern tables for ByteString in my
local libraries; it'd be trivial to extend that to intern tables for
String or Text or anything else supporting either (a) equality and
hashability, or (b) orderability. IMO, if users want an intern table
then they should ask for one, they shouldn't use some ad hoc
combination of other data types which obfuscates the true purpose.
Adding this to containers should be proposed on a separate thread, but
I'm entirely willing to do it if people actually want it

-- 
Live well,
~wren