From david.feuer at gmail.com  Sat Aug  3 00:00:20 2019
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 2 Aug 2019 20:00:20 -0400
Subject: Proposal: Remove Control.Monad.Instances
Message-ID: <CAMgWh9tzOtnwxxZY7woDKbBt5+E97vRPS_1ORiKdpn9t=x6xzA@mail.gmail.com>

The Control.Monad.Instances module in base has been deprecated since
base-4.6.0, which was released in 2012. I believe the time has long since
passed to actually remove the module, and I propose that we do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190802/8ebb119f/attachment.html>

From alexandreR_B at outlook.com  Sat Aug  3 00:04:57 2019
From: alexandreR_B at outlook.com (=?iso-8859-1?Q?Alexandre_Rodrigues_Bald=E9?=)
Date: Sat, 3 Aug 2019 00:04:57 +0000
Subject: Proposal: Remove Control.Monad.Instances
In-Reply-To: <CAMgWh9tzOtnwxxZY7woDKbBt5+E97vRPS_1ORiKdpn9t=x6xzA@mail.gmail.com>
References: <CAMgWh9tzOtnwxxZY7woDKbBt5+E97vRPS_1ORiKdpn9t=x6xzA@mail.gmail.com>
Message-ID: <PR2P264MB0206A151BEEFB98E8115F551FFD80@PR2P264MB0206.FRAP264.PROD.OUTLOOK.COM>

+1.
In this case, less is more.

________________________________
From: Libraries <libraries-bounces at haskell.org> on behalf of David Feuer <david.feuer at gmail.com>
Sent: Saturday, August 3, 2019 1:00:20 AM
To: Haskell Libraries <libraries at haskell.org>; core-libraries-committee at haskell.org <core-libraries-committee at haskell.org>
Subject: Proposal: Remove Control.Monad.Instances

The Control.Monad.Instances module in base has been deprecated since base-4.6.0, which was released in 2012. I believe the time has long since passed to actually remove the module, and I propose that we do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190803/2481b9c7/attachment.html>

From chessai1996 at gmail.com  Sat Aug  3 00:26:32 2019
From: chessai1996 at gmail.com (chessai .)
Date: Fri, 2 Aug 2019 20:26:32 -0400
Subject: Proposal: Remove Control.Monad.Instances
In-Reply-To: <PR2P264MB0206A151BEEFB98E8115F551FFD80@PR2P264MB0206.FRAP264.PROD.OUTLOOK.COM>
References: <CAMgWh9tzOtnwxxZY7woDKbBt5+E97vRPS_1ORiKdpn9t=x6xzA@mail.gmail.com>
 <PR2P264MB0206A151BEEFB98E8115F551FFD80@PR2P264MB0206.FRAP264.PROD.OUTLOOK.COM>
Message-ID: <CAD34_kLa6qG8LSiqmcFut0GOuWeyWqaaoDqWDgSuoTouFRNchA@mail.gmail.com>

+1

On Fri, Aug 2, 2019, 8:05 PM Alexandre Rodrigues Baldé <
alexandreR_B at outlook.com> wrote:

> +1.
>
> In this case, less is more.
>
>
> ------------------------------
> *From:* Libraries <libraries-bounces at haskell.org> on behalf of David
> Feuer <david.feuer at gmail.com>
> *Sent:* Saturday, August 3, 2019 1:00:20 AM
> *To:* Haskell Libraries <libraries at haskell.org>;
> core-libraries-committee at haskell.org <core-libraries-committee at haskell.org
> >
> *Subject:* Proposal: Remove Control.Monad.Instances
>
> The Control.Monad.Instances module in base has been deprecated since
> base-4.6.0, which was released in 2012. I believe the time has long since
> passed to actually remove the module, and I propose that we do so.
> _______________________________________________
> 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/20190802/166c2121/attachment.html>

From george at wils.online  Sat Aug  3 01:06:26 2019
From: george at wils.online (George Wilson)
Date: Sat, 3 Aug 2019 11:06:26 +1000
Subject: [core libraries] Re: Proposal: Remove Control.Monad.Instances
In-Reply-To: <CAD34_kLa6qG8LSiqmcFut0GOuWeyWqaaoDqWDgSuoTouFRNchA@mail.gmail.com>
References: <CAMgWh9tzOtnwxxZY7woDKbBt5+E97vRPS_1ORiKdpn9t=x6xzA@mail.gmail.com>
 <PR2P264MB0206A151BEEFB98E8115F551FFD80@PR2P264MB0206.FRAP264.PROD.OUTLOOK.COM>
 <CAD34_kLa6qG8LSiqmcFut0GOuWeyWqaaoDqWDgSuoTouFRNchA@mail.gmail.com>
Message-ID: <CABzzMazUL4_Vy6a8OU2=+vESQveDy32ZkwkFPwz+kfEKFaqYtw@mail.gmail.com>

+1

On Sat., 3 Aug. 2019, 10:26 chessai ., <chessai1996 at gmail.com> wrote:

> +1
>
> On Fri, Aug 2, 2019, 8:05 PM Alexandre Rodrigues Baldé <
> alexandreR_B at outlook.com> wrote:
>
>> +1.
>>
>> In this case, less is more.
>>
>>
>> ------------------------------
>> *From:* Libraries <libraries-bounces at haskell.org> on behalf of David
>> Feuer <david.feuer at gmail.com>
>> *Sent:* Saturday, August 3, 2019 1:00:20 AM
>> *To:* Haskell Libraries <libraries at haskell.org>;
>> core-libraries-committee at haskell.org <
>> core-libraries-committee at haskell.org>
>> *Subject:* Proposal: Remove Control.Monad.Instances
>>
>> The Control.Monad.Instances module in base has been deprecated since
>> base-4.6.0, which was released in 2012. I believe the time has long since
>> passed to actually remove the module, and I propose that we do so.
>> _______________________________________________
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kLa6qG8LSiqmcFut0GOuWeyWqaaoDqWDgSuoTouFRNchA%40mail.gmail.com
> <https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kLa6qG8LSiqmcFut0GOuWeyWqaaoDqWDgSuoTouFRNchA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190803/9c5b0472/attachment.html>

From david.feuer at gmail.com  Tue Aug  6 07:25:06 2019
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 6 Aug 2019 03:25:06 -0400
Subject: Request for comment on new package
Message-ID: <CAMgWh9tsqW364KQt8cTiiqskGWMLSA87yXU=61RZr2WWAihyPA@mail.gmail.com>

I've put together a small package for lazifying record types. There's a
"classy" version in Data.Lazify and a Generic-only version in
Data.Lazify.Generic. A few examples are below. I'd love to hear comments on
what looks good and what should be changed before I make the first release.
As usual, names are the hardest part. Note especially that the operator
($~) is defined in *both* Data.Lazify and Data.Lazify.Generic, and that no
operator corresponds to genericLazify. Hrmm mumble.

lazify (1, 2) = (1, 2)
lazify undefined = (_|_, _|_, _|_)
lazify undefined = Sum (_|_, _|_, _|_)

genericLazify (1,2) = (1,2)
genericLazify undefined = (_|_, _|_, _|_)
genericLazify (Sum (MyCon x y)) = ... oops, MyType isn't an instance of
Lazifiable

lazifyGeneric (1,2) = (1,2)
lazifyGeneric undefined = (_|_, _|_, _|_)
lazifyGeneric (Sum (MyCon x y)) = Sum (MyCon x y)

Thanks in advance,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190806/8448ebc1/attachment.html>

From david.feuer at gmail.com  Tue Aug  6 07:29:49 2019
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 6 Aug 2019 03:29:49 -0400
Subject: Request for comment on new package
In-Reply-To: <CAMgWh9tsqW364KQt8cTiiqskGWMLSA87yXU=61RZr2WWAihyPA@mail.gmail.com>
References: <CAMgWh9tsqW364KQt8cTiiqskGWMLSA87yXU=61RZr2WWAihyPA@mail.gmail.com>
Message-ID: <CAMgWh9sRuvLZs_eWFzXqtOV9pyMabJoDciwPdRL6L5C+6kfeEw@mail.gmail.com>

Of course, I forgot to actually link to the package candidate. Whoops!
Here it is:

http://hackage.haskell.org/package/lazify-0.1.0.0/candidate

On Tue, Aug 6, 2019 at 3:25 AM David Feuer <david.feuer at gmail.com> wrote:

> I've put together a small package for lazifying record types. There's a
> "classy" version in Data.Lazify and a Generic-only version in
> Data.Lazify.Generic. A few examples are below. I'd love to hear comments on
> what looks good and what should be changed before I make the first release.
> As usual, names are the hardest part. Note especially that the operator
> ($~) is defined in *both* Data.Lazify and Data.Lazify.Generic, and that no
> operator corresponds to genericLazify. Hrmm mumble.
>
> lazify (1, 2) = (1, 2)
> lazify undefined = (_|_, _|_, _|_)
> lazify undefined = Sum (_|_, _|_, _|_)
>
> genericLazify (1,2) = (1,2)
> genericLazify undefined = (_|_, _|_, _|_)
> genericLazify (Sum (MyCon x y)) = ... oops, MyType isn't an instance of
> Lazifiable
>
> lazifyGeneric (1,2) = (1,2)
> lazifyGeneric undefined = (_|_, _|_, _|_)
> lazifyGeneric (Sum (MyCon x y)) = Sum (MyCon x y)
>
> Thanks in advance,
> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190806/c1df784e/attachment.html>

From lambda.fairy at gmail.com  Tue Aug  6 07:55:42 2019
From: lambda.fairy at gmail.com (Chris Wong)
Date: Tue, 6 Aug 2019 19:55:42 +1200
Subject: Request for comment on new package
In-Reply-To: <CAMgWh9tsqW364KQt8cTiiqskGWMLSA87yXU=61RZr2WWAihyPA@mail.gmail.com>
References: <CAMgWh9tsqW364KQt8cTiiqskGWMLSA87yXU=61RZr2WWAihyPA@mail.gmail.com>
Message-ID: <CANQO64+khQNzpy8qo4BKvvBELaETXUA8u6-XVQWMVupkn=QVxQ@mail.gmail.com>

Hi David,

What are the use cases for such a package?

I'd love to see some examples of problems that can be solved with
Lazifiable.

Chris


On Tue, Aug 6, 2019, 19:25 David Feuer <david.feuer at gmail.com> wrote:

> I've put together a small package for lazifying record types. There's a
> "classy" version in Data.Lazify and a Generic-only version in
> Data.Lazify.Generic. A few examples are below. I'd love to hear comments on
> what looks good and what should be changed before I make the first release.
> As usual, names are the hardest part. Note especially that the operator
> ($~) is defined in *both* Data.Lazify and Data.Lazify.Generic, and that no
> operator corresponds to genericLazify. Hrmm mumble.
>
> lazify (1, 2) = (1, 2)
> lazify undefined = (_|_, _|_, _|_)
> lazify undefined = Sum (_|_, _|_, _|_)
>
> genericLazify (1,2) = (1,2)
> genericLazify undefined = (_|_, _|_, _|_)
> genericLazify (Sum (MyCon x y)) = ... oops, MyType isn't an instance of
> Lazifiable
>
> lazifyGeneric (1,2) = (1,2)
> lazifyGeneric undefined = (_|_, _|_, _|_)
> lazifyGeneric (Sum (MyCon x y)) = Sum (MyCon x y)
>
> Thanks in advance,
> 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/20190806/c65d6012/attachment.html>

From david.feuer at gmail.com  Tue Aug  6 08:17:41 2019
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 6 Aug 2019 04:17:41 -0400
Subject: Request for comment on new package
In-Reply-To: <CANQO64+khQNzpy8qo4BKvvBELaETXUA8u6-XVQWMVupkn=QVxQ@mail.gmail.com>
References: <CAMgWh9tsqW364KQt8cTiiqskGWMLSA87yXU=61RZr2WWAihyPA@mail.gmail.com>
 <CANQO64+khQNzpy8qo4BKvvBELaETXUA8u6-XVQWMVupkn=QVxQ@mail.gmail.com>
Message-ID: <CAMgWh9t0U_kBrEe8qrgkzuStvJotg52NNUMdVf0bZ0SsVrwWNw@mail.gmail.com>

A while back I complained to Ed Kmett that the `Bifunctor` instance for (,)
isn't strictly law abiding. Specifically,

  bimap id id _|_ = (_|_, _|_)

while by the first law we should really have

  bimap id id _|_ = _|_

He countered that for some purposes the extra laziness is necessary, and
that it's rather less convenient to lazify a pair than to force one (unless
you use something like forcePair[*] from utility-ht, which is another
one-trick pony to remember). This package is my attempt to prove to Ed that
lazifying is almost as easy as strictifying.

[*]
http://hackage.haskell.org/package/utility-ht-0.0.14/docs/Data-Tuple-Lazy.html#v:forcePair

On Tue, Aug 6, 2019, 3:55 AM Chris Wong <lambda.fairy at gmail.com> wrote:

> Hi David,
>
> What are the use cases for such a package?
>
> I'd love to see some examples of problems that can be solved with
> Lazifiable.
>
> Chris
>
>
> On Tue, Aug 6, 2019, 19:25 David Feuer <david.feuer at gmail.com> wrote:
>
>> I've put together a small package for lazifying record types. There's a
>> "classy" version in Data.Lazify and a Generic-only version in
>> Data.Lazify.Generic. A few examples are below. I'd love to hear comments on
>> what looks good and what should be changed before I make the first release.
>> As usual, names are the hardest part. Note especially that the operator
>> ($~) is defined in *both* Data.Lazify and Data.Lazify.Generic, and that no
>> operator corresponds to genericLazify. Hrmm mumble.
>>
>> lazify (1, 2) = (1, 2)
>> lazify undefined = (_|_, _|_, _|_)
>> lazify undefined = Sum (_|_, _|_, _|_)
>>
>> genericLazify (1,2) = (1,2)
>> genericLazify undefined = (_|_, _|_, _|_)
>> genericLazify (Sum (MyCon x y)) = ... oops, MyType isn't an instance of
>> Lazifiable
>>
>> lazifyGeneric (1,2) = (1,2)
>> lazifyGeneric undefined = (_|_, _|_, _|_)
>> lazifyGeneric (Sum (MyCon x y)) = Sum (MyCon x y)
>>
>> Thanks in advance,
>> 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/20190806/e91be6de/attachment.html>

From ndospark320 at gmail.com  Tue Aug  6 13:57:55 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Tue, 6 Aug 2019 22:57:55 +0900
Subject: foldrM definition
Message-ID: <CAKM3oZWKHXgYQV3En63e6ZQCot93kOmjNdLxsJ7yUYAuQ1gtug@mail.gmail.com>

Wouldn't it be friendlier to list structures if foldl' was used instead of
foldl?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190806/b6335d3a/attachment.html>

From david.feuer at gmail.com  Tue Aug  6 14:08:38 2019
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 6 Aug 2019 10:08:38 -0400
Subject: foldrM definition
In-Reply-To: <CAKM3oZWKHXgYQV3En63e6ZQCot93kOmjNdLxsJ7yUYAuQ1gtug@mail.gmail.com>
References: <CAKM3oZWKHXgYQV3En63e6ZQCot93kOmjNdLxsJ7yUYAuQ1gtug@mail.gmail.com>
Message-ID: <CAMgWh9vypT+hcmm=Spd4knAgO7YdpHO2Q6PXE9RhdD1niP_SHQ@mail.gmail.com>

Not likely. I don't think there's really any way to make it very friendly
to lists. Remember that the "accumulator" here is a *function*. Forcing
that function isn't likely to do you any good. foldrM is mainly for
containers that can be traversed from right to left anyways.

On Tue, Aug 6, 2019, 9:58 AM Dannyu NDos <ndospark320 at gmail.com> wrote:

> Wouldn't it be friendlier to list structures if foldl' was used instead of
> foldl?
> _______________________________________________
> 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/20190806/228f3fe9/attachment.html>

From ndospark320 at gmail.com  Tue Aug  6 19:40:09 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Wed, 7 Aug 2019 04:40:09 +0900
Subject: Add instance Alternative (Either e)
Message-ID: <CAKM3oZVavKbfzfLAPkF1SmQx=+gz=yBE3YWH_H9uwTGyCEew-g@mail.gmail.com>

instance Monoid e => Alternative (Either e) where
    empty = left mempty
    Left x <|> Left y = Left (x <> y)
    Left _ <|> y = y
    x <|> _ = x

Leftmost Right is returned for sake of consistence with Semigroup instance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190807/44f1ab43/attachment.html>

From ndospark320 at gmail.com  Tue Aug  6 19:44:33 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Wed, 7 Aug 2019 04:44:33 +0900
Subject: Add instance Alternative (f :+: g)
Message-ID: <CAKM3oZVmY9SH60ad4dL5T_0qtR4A5rVfkOeDENj3jmaJoBXXPA@mail.gmail.com>

instance Alternative f => Alternative (f :+: g) where
    empty = InL empty
    InL x <|> InL y = InL (x <|> y)
    InL _ <|> y = y
    x <|> _ = x

This is analogous to the proposed Alternative Either instance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190807/2749cf0d/attachment.html>

From ndospark320 at gmail.com  Tue Aug  6 19:50:20 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Wed, 7 Aug 2019 04:50:20 +0900
Subject: Add instance Monoid ((f :+: g) a)
Message-ID: <CAKM3oZVzS+50B8DdttFq6O95Kd+87LJEGznubk3Q_4ht2VK1aw@mail.gmail.com>

Ah, sorry. (:+:) is not an Applicative. It's still possible to make
instance Monoid:

instance Semigroup (f a) => Semigroup ((f :+: g) a) where
    InL x <> InL y = InL (x <> y)
    InL _ <> y = y
    x <> _ = x

instance Monoid (f a) => Monoid ((f :+: g) a) where
    mempty = InL mempty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190807/e4e24dcf/attachment.html>

From ndospark320 at gmail.com  Tue Aug  6 19:51:15 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Wed, 7 Aug 2019 04:51:15 +0900
Subject: Fwd: Add instance Monoid ((f :+: g) a)
In-Reply-To: <CAKM3oZVzS+50B8DdttFq6O95Kd+87LJEGznubk3Q_4ht2VK1aw@mail.gmail.com>
References: <CAKM3oZVzS+50B8DdttFq6O95Kd+87LJEGznubk3Q_4ht2VK1aw@mail.gmail.com>
Message-ID: <CAKM3oZVBOiQODHehHdjH9pfBm1v7a1AJFuya=ridbJ+Gq+rysQ@mail.gmail.com>

---------- Forwarded message ---------
보낸사람: Dannyu NDos <ndospark320 at gmail.com>
Date: 2019년 8월 7일 (수) 04:50
Subject: Re: Add instance Monoid ((f :+: g) a)
To: Haskell Libraries <libraries at haskell.org>


Ah, sorry. (:+:) is not an Applicative. It's still possible to make
instance Monoid:

instance Semigroup (f a) => Semigroup ((f :+: g) a) where
    InL x <> InL y = InL (x <> y)
    InL _ <> y = y
    x <> _ = x

instance Monoid (f a) => Monoid ((f :+: g) a) where
    mempty = InL mempty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190807/b977fb2d/attachment.html>

From hvriedel at gmail.com  Thu Aug  8 05:37:35 2019
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 8 Aug 2019 07:37:35 +0200
Subject: Add instance Alternative (Either e)
In-Reply-To: <CAKM3oZVavKbfzfLAPkF1SmQx=+gz=yBE3YWH_H9uwTGyCEew-g@mail.gmail.com>
References: <CAKM3oZVavKbfzfLAPkF1SmQx=+gz=yBE3YWH_H9uwTGyCEew-g@mail.gmail.com>
Message-ID: <CAOFsArtzAuBeT+Rhs3u7WoDSDbC+wNS3Vp4-uo0_4sGxpaQizA@mail.gmail.com>

On Tue, Aug 6, 2019 at 9:40 PM Dannyu NDos <ndospark320 at gmail.com> wrote:
> instance Monoid e => Alternative (Either e) where
>     empty = left mempty
>     Left x <|> Left y = Left (x <> y)
>     Left _ <|> y = y
>     x <|> _ = x
>
> Leftmost Right is returned for sake of consistence with Semigroup instance.

Related: https://ghc.haskell.org/trac/ghc/ticket/9588

From mblazevic at stilo.com  Fri Aug  9 18:11:17 2019
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Fri, 9 Aug 2019 14:11:17 -0400
Subject: Request for comment on new package
In-Reply-To: <CAMgWh9sRuvLZs_eWFzXqtOV9pyMabJoDciwPdRL6L5C+6kfeEw@mail.gmail.com>
References: <CAMgWh9tsqW364KQt8cTiiqskGWMLSA87yXU=61RZr2WWAihyPA@mail.gmail.com>
 <CAMgWh9sRuvLZs_eWFzXqtOV9pyMabJoDciwPdRL6L5C+6kfeEw@mail.gmail.com>
Message-ID: <53a016a5-6358-404e-4e81-068a21a54ad9@stilo.com>

On 2019-08-06 3:29 a.m., David Feuer wrote:
> Of course, I forgot to actually link to the package candidate. Whoops!
> Here it is:
> 
> http://hackage.haskell.org/package/lazify-0.1.0.0/candidate

I think lazy would be a better function name than lazify. Generally 
speaking, verbs (i.e., actions) should bind to monadic functions.

You put a lot of faith in GHC optimizations. I wouldn't rely on the 
default lazify = glazify implementation so much.

Finally, some missing instances from base:

- a -> b
- NonEmpty
- Complex
- Alt
- Par1
- Rec1

From david.feuer at gmail.com  Fri Aug  9 18:40:48 2019
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 10 Aug 2019 01:40:48 +0700
Subject: Request for comment on new package
In-Reply-To: <53a016a5-6358-404e-4e81-068a21a54ad9@stilo.com>
References: <CAMgWh9tsqW364KQt8cTiiqskGWMLSA87yXU=61RZr2WWAihyPA@mail.gmail.com>
 <CAMgWh9sRuvLZs_eWFzXqtOV9pyMabJoDciwPdRL6L5C+6kfeEw@mail.gmail.com>
 <53a016a5-6358-404e-4e81-068a21a54ad9@stilo.com>
Message-ID: <CAMgWh9ude_Vuo-myCamM=cAwKtmqShAAosmd1cSY-Fbx5XWgJw@mail.gmail.com>

It's not faith; I checked the Core for the instances and found they all
optimized properly, and produced optimized unfoldings. Complex has a
totally strict constructor, which I think means it shouldn't have a
Lazifiable instance. Good point about NonEmpty and the extra newtypes. I've
thought about (a -> b), but it's not totally clear to me which instance is
best. For consistency, probably

lazify f x = f x

but is that really useful and clear?

I'd be okay with lazy rather than lazify, but that clashes with
GHC.Exts.lazy. How bad is that? How would you name the classes and package?

On Sat, Aug 10, 2019, 1:11 AM Mario Blažević <mblazevic at stilo.com> wrote:

> On 2019-08-06 3:29 a.m., David Feuer wrote:
> > Of course, I forgot to actually link to the package candidate. Whoops!
> > Here it is:
> >
> > http://hackage.haskell.org/package/lazify-0.1.0.0/candidate
>
> I think lazy would be a better function name than lazify. Generally
> speaking, verbs (i.e., actions) should bind to monadic functions.
>
> You put a lot of faith in GHC optimizations. I wouldn't rely on the
> default lazify = glazify implementation so much.
>
> Finally, some missing instances from base:
>
> - a -> b
> - NonEmpty
> - Complex
> - Alt
> - Par1
> - Rec1
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190810/0cb1e2de/attachment.html>

From jp at jamesparker.me  Fri Aug  9 18:48:55 2019
From: jp at jamesparker.me (James Parker)
Date: Fri, 9 Aug 2019 14:48:55 -0400
Subject: Request for comment on new package
In-Reply-To: <CAMgWh9ude_Vuo-myCamM=cAwKtmqShAAosmd1cSY-Fbx5XWgJw@mail.gmail.com>
References: <CAMgWh9tsqW364KQt8cTiiqskGWMLSA87yXU=61RZr2WWAihyPA@mail.gmail.com>
 <CAMgWh9sRuvLZs_eWFzXqtOV9pyMabJoDciwPdRL6L5C+6kfeEw@mail.gmail.com>
 <53a016a5-6358-404e-4e81-068a21a54ad9@stilo.com>
 <CAMgWh9ude_Vuo-myCamM=cAwKtmqShAAosmd1cSY-Fbx5XWgJw@mail.gmail.com>
Message-ID: <A266AFAF-CF4C-4946-A202-2DD61CE0CDBC@jamesparker.me>

Maybe you can use inspection-testing <https://hackage.haskell.org/package/inspection-testing> to add test cases to ensure that these optimizations do not go away in the future. 

> On Aug 9, 2019, at 2:40 PM, David Feuer <david.feuer at gmail.com> wrote:
> 
> It's not faith; I checked the Core for the instances and found they all optimized properly, and produced optimized unfoldings. Complex has a totally strict constructor, which I think means it shouldn't have a Lazifiable instance. Good point about NonEmpty and the extra newtypes. I've thought about (a -> b), but it's not totally clear to me which instance is best. For consistency, probably
> 
> lazify f x = f x
> 
> but is that really useful and clear?
> 
> I'd be okay with lazy rather than lazify, but that clashes with GHC.Exts.lazy. How bad is that? How would you name the classes and package?
> 
> On Sat, Aug 10, 2019, 1:11 AM Mario Blažević <mblazevic at stilo.com <mailto:mblazevic at stilo.com>> wrote:
> On 2019-08-06 3:29 a.m., David Feuer wrote:
> > Of course, I forgot to actually link to the package candidate. Whoops!
> > Here it is:
> > 
> > http://hackage.haskell.org/package/lazify-0.1.0.0/candidate <http://hackage.haskell.org/package/lazify-0.1.0.0/candidate>
> 
> I think lazy would be a better function name than lazify. Generally 
> speaking, verbs (i.e., actions) should bind to monadic functions.
> 
> You put a lot of faith in GHC optimizations. I wouldn't rely on the 
> default lazify = glazify implementation so much.
> 
> Finally, some missing instances from base:
> 
> - a -> b
> - NonEmpty
> - Complex
> - Alt
> - Par1
> - Rec1
> _______________________________________________
> 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/20190809/27824549/attachment.html>

From ndospark320 at gmail.com  Sat Aug 10 01:14:59 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Sat, 10 Aug 2019 10:14:59 +0900
Subject: Add instance Eq1 Complex, Show1 Complex, and Read1 Complex
Message-ID: <CAKM3oZX=dR-QyvakgSJhrY-wGq=Xi_Wa402y8iNHSPU70S_jbQ@mail.gmail.com>

instance Eq1 Complex where
liftEq f (x :+ y) (u :+ v) = f x u && f y v

instance Show1 Complex where
liftShowsPrec sp _ p (x :+ y) = showParen (p >= 6) (sp p x . showString "
:+ " . sp p y)

instance Read1 Complex where
liftReadPrec rp _ = parens $ prec 6 $ do
x <- step rp
Symbol ":+" <- lexP
y <- step rp
return (x :+ y)
liftReadList = liftReadListDefault
liftReadListPrec = liftReadListPrecDefault
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190810/c6db798c/attachment.html>

From ekmett at gmail.com  Sat Aug 10 02:26:30 2019
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 9 Aug 2019 19:26:30 -0700
Subject: Add instance Eq1 Complex, Show1 Complex, and Read1 Complex
In-Reply-To: <CAKM3oZX=dR-QyvakgSJhrY-wGq=Xi_Wa402y8iNHSPU70S_jbQ@mail.gmail.com>
References: <CAKM3oZX=dR-QyvakgSJhrY-wGq=Xi_Wa402y8iNHSPU70S_jbQ@mail.gmail.com>
Message-ID: <CAJumaK9eUZQUy9b-R6Vhyp0LtGr5Fsk-LXWO9pAdVAQZe8Xaew@mail.gmail.com>

Makes sense to me. +1

On Fri, Aug 9, 2019 at 6:15 PM Dannyu NDos <ndospark320 at gmail.com> wrote:

> instance Eq1 Complex where
> liftEq f (x :+ y) (u :+ v) = f x u && f y v
>
> instance Show1 Complex where
> liftShowsPrec sp _ p (x :+ y) = showParen (p >= 6) (sp p x . showString "
> :+ " . sp p y)
>
> instance Read1 Complex where
> liftReadPrec rp _ = parens $ prec 6 $ do
> x <- step rp
> Symbol ":+" <- lexP
> y <- step rp
> return (x :+ y)
> liftReadList = liftReadListDefault
> liftReadListPrec = liftReadListPrecDefault
> _______________________________________________
> 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/20190809/907abf21/attachment.html>

From chessai1996 at gmail.com  Sat Aug 10 02:50:29 2019
From: chessai1996 at gmail.com (chessai .)
Date: Fri, 9 Aug 2019 22:50:29 -0400
Subject: Add instance Eq1 Complex, Show1 Complex, and Read1 Complex
In-Reply-To: <CAJumaK9eUZQUy9b-R6Vhyp0LtGr5Fsk-LXWO9pAdVAQZe8Xaew@mail.gmail.com>
References: <CAKM3oZX=dR-QyvakgSJhrY-wGq=Xi_Wa402y8iNHSPU70S_jbQ@mail.gmail.com>
 <CAJumaK9eUZQUy9b-R6Vhyp0LtGr5Fsk-LXWO9pAdVAQZe8Xaew@mail.gmail.com>
Message-ID: <CAD34_kJAXDwAS09w6-6g1aUn8pts0Fj0=FAyHqBVjK=M=p5T1A@mail.gmail.com>

+1

On Fri, Aug 9, 2019, 10:26 PM Edward Kmett <ekmett at gmail.com> wrote:

> Makes sense to me. +1
>
> On Fri, Aug 9, 2019 at 6:15 PM Dannyu NDos <ndospark320 at gmail.com> wrote:
>
>> instance Eq1 Complex where
>> liftEq f (x :+ y) (u :+ v) = f x u && f y v
>>
>> instance Show1 Complex where
>> liftShowsPrec sp _ p (x :+ y) = showParen (p >= 6) (sp p x . showString "
>> :+ " . sp p y)
>>
>> instance Read1 Complex where
>> liftReadPrec rp _ = parens $ prec 6 $ do
>> x <- step rp
>> Symbol ":+" <- lexP
>> y <- step rp
>> return (x :+ y)
>> liftReadList = liftReadListDefault
>> liftReadListPrec = liftReadListPrecDefault
>> _______________________________________________
>> 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/20190809/9fc142da/attachment.html>

From ndospark320 at gmail.com  Sun Aug 11 19:37:54 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Mon, 12 Aug 2019 04:37:54 +0900
Subject: Add instance MonadFail (f :*: g)
Message-ID: <CAKM3oZVPOx9fhFuTv+75WNiuAGYOF910y5-HknxOh47avXaOcA@mail.gmail.com>

instance (MonadFail f, MonadFail g) => MonadFail (f :*: g) where
    fail s = fail s :*: fail s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190812/6813f480/attachment.html>

From george at wils.online  Sun Aug 11 23:12:14 2019
From: george at wils.online (George Wilson)
Date: Mon, 12 Aug 2019 09:12:14 +1000
Subject: Add instance Eq1 Complex, Show1 Complex, and Read1 Complex
In-Reply-To: <CAD34_kJAXDwAS09w6-6g1aUn8pts0Fj0=FAyHqBVjK=M=p5T1A@mail.gmail.com>
References: <CAKM3oZX=dR-QyvakgSJhrY-wGq=Xi_Wa402y8iNHSPU70S_jbQ@mail.gmail.com>
 <CAJumaK9eUZQUy9b-R6Vhyp0LtGr5Fsk-LXWO9pAdVAQZe8Xaew@mail.gmail.com>
 <CAD34_kJAXDwAS09w6-6g1aUn8pts0Fj0=FAyHqBVjK=M=p5T1A@mail.gmail.com>
Message-ID: <CABzzMazmmRanZNTT0h0ALXZEXDgeVWBtof7UMpOem2cwgBAG1Q@mail.gmail.com>

+1

On Sat, 10 Aug 2019 at 12:51, chessai . <chessai1996 at gmail.com> wrote:
>
> +1
>
> On Fri, Aug 9, 2019, 10:26 PM Edward Kmett <ekmett at gmail.com> wrote:
>>
>> Makes sense to me. +1
>>
>> On Fri, Aug 9, 2019 at 6:15 PM Dannyu NDos <ndospark320 at gmail.com> wrote:
>>>
>>> instance Eq1 Complex where
>>> liftEq f (x :+ y) (u :+ v) = f x u && f y v
>>>
>>> instance Show1 Complex where
>>> liftShowsPrec sp _ p (x :+ y) = showParen (p >= 6) (sp p x . showString " :+ " . sp p y)
>>>
>>> instance Read1 Complex where
>>> liftReadPrec rp _ = parens $ prec 6 $ do
>>> x <- step rp
>>> Symbol ":+" <- lexP
>>> y <- step rp
>>> return (x :+ y)
>>> liftReadList = liftReadListDefault
>>> liftReadListPrec = liftReadListPrecDefault
>>> _______________________________________________
>>> 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

From ekmett at gmail.com  Mon Aug 12 08:18:57 2019
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 12 Aug 2019 01:18:57 -0700
Subject: Add instance MonadFail (f :*: g)
In-Reply-To: <CAKM3oZVPOx9fhFuTv+75WNiuAGYOF910y5-HknxOh47avXaOcA@mail.gmail.com>
References: <CAKM3oZVPOx9fhFuTv+75WNiuAGYOF910y5-HknxOh47avXaOcA@mail.gmail.com>
Message-ID: <CAJumaK_gQf0ALX3bmvZAFJvy_Qxg36A5P0j1AtVMFWGm2JpRLg@mail.gmail.com>

Works for me. +1

On Sun, Aug 11, 2019 at 12:38 PM Dannyu NDos <ndospark320 at gmail.com> wrote:

> instance (MonadFail f, MonadFail g) => MonadFail (f :*: g) where
>     fail s = fail s :*: fail s
> _______________________________________________
> 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/20190812/17a4626d/attachment.html>

From taylor at fausak.me  Mon Aug 12 16:14:37 2019
From: taylor at fausak.me (Taylor Fausak)
Date: Mon, 12 Aug 2019 12:14:37 -0400
Subject: Proposal: Add singleton function to Data.List module
Message-ID: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>

I originally made this suggestion on GitLab, but I was told to make it here instead.

https://gitlab.haskell.org/ghc/ghc/issues/17042

---

# Add list singleton function

## Motivation

Sometimes it is convenient to have a function to wrap an element in a list. There are many ways to do this already, but none of them are as clear as a separate monomorphic function.

- `pure`: Polymorphic, works for any `Functor`.
- `pure @[]`: Noisy, requires `-XTypeApplications`.
- `(: [])`: Subjectively ugly.
- `(\x -> [x])`: Syntactically noisy.

This Twitter thread includes some additional commentary: https://twitter.com/taylorfausak/status/1159264862247280640

## Proposal

I would like to add a `singleton` function to `Data.List` that mirrors the `singleton` function for other containers: https://www.stackage.org/lts-14.0/hoogle?q=singleton

``` hs
singleton :: a -> [a]
singleton x = [x]
```

Other Haskell-like languages include this function:

- PureScript: https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.List#v:singleton
- Elm: https://package.elm-lang.org/packages/elm/core/latest/List#singleton

From ollie at ocharles.org.uk  Mon Aug 12 17:02:42 2019
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Mon, 12 Aug 2019 18:02:42 +0100
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
Message-ID: <CAGRp5Rm1_nU-Xisr-ktbL9t73XuyCPA7vx_JO2Lq0wSs3OZjKw@mail.gmail.com>

+1. All alternatives to construct a list "anonymously" are confusing
and take time to parse. An explicit `Data.List.singleton x` is very
clear what's going on.

On Mon, Aug 12, 2019 at 5:14 PM Taylor Fausak <taylor at fausak.me> wrote:
>
> I originally made this suggestion on GitLab, but I was told to make it here instead.
>
> https://gitlab.haskell.org/ghc/ghc/issues/17042
>
> ---
>
> # Add list singleton function
>
> ## Motivation
>
> Sometimes it is convenient to have a function to wrap an element in a list. There are many ways to do this already, but none of them are as clear as a separate monomorphic function.
>
> - `pure`: Polymorphic, works for any `Functor`.
> - `pure @[]`: Noisy, requires `-XTypeApplications`.
> - `(: [])`: Subjectively ugly.
> - `(\x -> [x])`: Syntactically noisy.
>
> This Twitter thread includes some additional commentary: https://twitter.com/taylorfausak/status/1159264862247280640
>
> ## Proposal
>
> I would like to add a `singleton` function to `Data.List` that mirrors the `singleton` function for other containers: https://www.stackage.org/lts-14.0/hoogle?q=singleton
>
> ``` hs
> singleton :: a -> [a]
> singleton x = [x]
> ```
>
> Other Haskell-like languages include this function:
>
> - PureScript: https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.List#v:singleton
> - Elm: https://package.elm-lang.org/packages/elm/core/latest/List#singleton
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From hvriedel at gmail.com  Mon Aug 12 17:03:28 2019
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Mon, 12 Aug 2019 19:03:28 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
Message-ID: <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>

> - `(:[])`: Subjectively ugly.

I consider "subjectively ugly" to be a non-technical and thus really
weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])
which also happens to be shorter than the proposed alias for it. I for
one don't see a significant benefit for adding a redundant synonym to
`Data.List` and are thus -1 on this.

> singleton :: a -> [a]
> singleton x = [x]

From ollie at ocharles.org.uk  Mon Aug 12 17:10:19 2019
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Mon, 12 Aug 2019 18:10:19 +0100
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
Message-ID: <CAGRp5RnYDj=AowtzybpjW0OqN0p6fB624aE_RJbc-+Um2qjx_g@mail.gmail.com>

On Mon, Aug 12, 2019 at 6:03 PM Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:
>
> > - `(:[])`: Subjectively ugly.
>
> I consider "subjectively ugly" to be a non-technical and thus really
> weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])
> which also happens to be shorter than the proposed alias for it. I for
> one don't see a significant benefit for adding a redundant synonym to
> `Data.List` and are thus -1 on this.

You are of course entitled to see this as a weak argument, but those
of us who are writing Haskell for 8 hours a day do not make all of our
decisions based on purely "technical" arguments. How easy it is for
myself and colleagues to review code is significant.

On the other hand, "the existing alternative happens to be shorter"
*is* a weak argument to me. There is no tax on characters typed, and
IMO we should be evaluating this change on whether or not it
contributes to code clarity, rather than "is long to type". Unless you
consider "singleton" to be so long it further obscures code, but I
have a hard time buying that.

Ollie

From strake888 at gmail.com  Mon Aug 12 17:20:14 2019
From: strake888 at gmail.com (Matthew Farkas-Dyck)
Date: Mon, 12 Aug 2019 09:20:14 -0800
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
Message-ID: <CAL3m8eBTzk9s4bGfXQZxBXVpg+zV41XQovGJ+pQZFsY=7-7R+A@mail.gmail.com>

-1, not worth increasing the size of base as `pure` works perfectly well

From parsonsmatt at gmail.com  Mon Aug 12 17:20:23 2019
From: parsonsmatt at gmail.com (Matt)
Date: Mon, 12 Aug 2019 11:20:23 -0600
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAGRp5RnYDj=AowtzybpjW0OqN0p6fB624aE_RJbc-+Um2qjx_g@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
 <CAGRp5RnYDj=AowtzybpjW0OqN0p6fB624aE_RJbc-+Um2qjx_g@mail.gmail.com>
Message-ID: <CA+4qU94NJ9ocvRaBbw3Nf1=Hk=EhX6hDgWKxGC66KHTuHfww8A@mail.gmail.com>

I'm +1 on this.

It's nice to have a relatively consistent naming scheme between
container-types - `Data.Set` and `Data.Map` sharing mostly the same API
names is really helpful for writing code without having to look up the
specifics.  The `(:[])` operator takes me a decent amount longer to parse
and recognize, and I have seen intermediate-level Haskellers trip up over
unspaced operators like this in several contexts. Container-specific
functions can be really useful to fix an ambiguous type in a long sequence
of constrained polymorphic functions (like `length "hello"` becoming
ambiguous with `OverloadedStrings`), and I've written `pure @[]` before to
provide this disambiguation.

As far as I can tell, it's consistent, convenient, useful, and obvious.
This IMO makes it a good candidate for inclusion.

Matt Parsons


On Mon, Aug 12, 2019 at 11:10 AM Oliver Charles <ollie at ocharles.org.uk>
wrote:

> On Mon, Aug 12, 2019 at 6:03 PM Herbert Valerio Riedel
> <hvriedel at gmail.com> wrote:
> >
> > > - `(:[])`: Subjectively ugly.
> >
> > I consider "subjectively ugly" to be a non-technical and thus really
> > weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])
> > which also happens to be shorter than the proposed alias for it. I for
> > one don't see a significant benefit for adding a redundant synonym to
> > `Data.List` and are thus -1 on this.
>
> You are of course entitled to see this as a weak argument, but those
> of us who are writing Haskell for 8 hours a day do not make all of our
> decisions based on purely "technical" arguments. How easy it is for
> myself and colleagues to review code is significant.
>
> On the other hand, "the existing alternative happens to be shorter"
> *is* a weak argument to me. There is no tax on characters typed, and
> IMO we should be evaluating this change on whether or not it
> contributes to code clarity, rather than "is long to type". Unless you
> consider "singleton" to be so long it further obscures code, but I
> have a hard time buying that.
>
> Ollie
> _______________________________________________
> 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/20190812/0d9d00e6/attachment.html>

From ollie at ocharles.org.uk  Mon Aug 12 17:21:52 2019
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Mon, 12 Aug 2019 18:21:52 +0100
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAGRp5RnYDj=AowtzybpjW0OqN0p6fB624aE_RJbc-+Um2qjx_g@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
 <CAGRp5RnYDj=AowtzybpjW0OqN0p6fB624aE_RJbc-+Um2qjx_g@mail.gmail.com>
Message-ID: <CAGRp5RnX5T=nvUe+zyJukaAiswAQ_hx_+ET3zCidf90CAx2udA@mail.gmail.com>

On Mon, Aug 12, 2019 at 6:10 PM Oliver Charles <ollie at ocharles.org.uk> wrote:

> You are of course entitled to see this as a weak argument, but those
> of us who are writing Haskell for 8 hours a day do not make all of our
> decisions based on purely "technical" arguments. How easy it is for
> myself and colleagues to review code is significant.

Apologies, I see now this statement reads like 'I write more code that
hvr, so his opinion is worth less'. That wasn't my intention, in fact
I wasn't trying to provide any type of judgement as to how much hvr
writes (as I understand it, hvr writes plenty!). I was just trying to
emphasize how much this proposal means to me as a full time Haskell
programmer.

Seeing as I'm already derailing the conversation I'll step out of this
for now. Turns out I'm weirdly passionate about this single
expression!

From zemyla at gmail.com  Mon Aug 12 17:35:22 2019
From: zemyla at gmail.com (Zemyla)
Date: Mon, 12 Aug 2019 12:35:22 -0500
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
Message-ID: <CAK7nUjjOOa_E_UbjV1fDirYKrizxsZf7CXaGmWMhMNHR62-qpg@mail.gmail.com>

I also like the ninja-robot operator, because it's visually
interesting and easy to search for.

Also, if you're importing several libraries which already use
"singleton", then you have to use "List.singleton" every time, which
is far uglier to me.

On Mon, Aug 12, 2019 at 12:03 PM Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:
>
> > - `(:[])`: Subjectively ugly.
>
> I consider "subjectively ugly" to be a non-technical and thus really
> weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])
> which also happens to be shorter than the proposed alias for it. I for
> one don't see a significant benefit for adding a redundant synonym to
> `Data.List` and are thus -1 on this.
>
> > singleton :: a -> [a]
> > singleton x = [x]
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From byorgey at gmail.com  Mon Aug 12 18:36:43 2019
From: byorgey at gmail.com (Brent Yorgey)
Date: Mon, 12 Aug 2019 13:36:43 -0500
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAK7nUjjOOa_E_UbjV1fDirYKrizxsZf7CXaGmWMhMNHR62-qpg@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
 <CAK7nUjjOOa_E_UbjV1fDirYKrizxsZf7CXaGmWMhMNHR62-qpg@mail.gmail.com>
Message-ID: <CAH0njdsmq_iqAG+y2tz3TovOSAQkUPh-e_HndFQ8oJDmSAHQ=A@mail.gmail.com>

At the risk of completely derailing the conversation, I have always called
this the "robot monkey operator".  I fail to see what is so ninja-like
about it.

Anyway, I think I am +1 on adding Data.List.singleton.

-Brent

On Mon, Aug 12, 2019, 12:35 PM Zemyla <zemyla at gmail.com> wrote:

> I also like the ninja-robot operator, because it's visually
> interesting and easy to search for.
>
> Also, if you're importing several libraries which already use
> "singleton", then you have to use "List.singleton" every time, which
> is far uglier to me.
>
> On Mon, Aug 12, 2019 at 12:03 PM Herbert Valerio Riedel
> <hvriedel at gmail.com> wrote:
> >
> > > - `(:[])`: Subjectively ugly.
> >
> > I consider "subjectively ugly" to be a non-technical and thus really
> > weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])
> > which also happens to be shorter than the proposed alias for it. I for
> > one don't see a significant benefit for adding a redundant synonym to
> > `Data.List` and are thus -1 on this.
> >
> > > singleton :: a -> [a]
> > > singleton x = [x]
> > _______________________________________________
> > 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/20190812/f64c2c97/attachment.html>

From andrew.lelechenko at gmail.com  Mon Aug 12 19:52:57 2019
From: andrew.lelechenko at gmail.com (Andrew Lelechenko)
Date: Mon, 12 Aug 2019 20:52:57 +0100
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAH0njdsmq_iqAG+y2tz3TovOSAQkUPh-e_HndFQ8oJDmSAHQ=A@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
 <CAK7nUjjOOa_E_UbjV1fDirYKrizxsZf7CXaGmWMhMNHR62-qpg@mail.gmail.com>
 <CAH0njdsmq_iqAG+y2tz3TovOSAQkUPh-e_HndFQ8oJDmSAHQ=A@mail.gmail.com>
Message-ID: <C3BDE1D7-AB22-4A68-AA0A-3B5CD82173FC@gmail.com>

> - `pure`: Polymorphic, works for any `Functor`.

It is OK to have polymorphic folds and length, so what is wrong with pure? 

Adding singleton to Data.List is a breaking change, when Data.Map.singleton was exported unqualified. 
And there is no singleton in Data.List.NonEmpty as well. 

-1 from me.

Best regards,
Andrew

> On 12 Aug 2019, at 19:36, Brent Yorgey <byorgey at gmail.com> wrote:
> 
> At the risk of completely derailing the conversation, I have always called this the "robot monkey operator".  I fail to see what is so ninja-like about it.
> 
> Anyway, I think I am +1 on adding Data.List.singleton.
> 
> -Brent
> 
> On Mon, Aug 12, 2019, 12:35 PM Zemyla <zemyla at gmail.com <mailto:zemyla at gmail.com>> wrote:
> I also like the ninja-robot operator, because it's visually
> interesting and easy to search for.
> 
> Also, if you're importing several libraries which already use
> "singleton", then you have to use "List.singleton" every time, which
> is far uglier to me.
> 
> On Mon, Aug 12, 2019 at 12:03 PM Herbert Valerio Riedel
> <hvriedel at gmail.com <mailto:hvriedel at gmail.com>> wrote:
> >
> > > - `(:[])`: Subjectively ugly.
> >
> > I consider "subjectively ugly" to be a non-technical and thus really
> > weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])
> > which also happens to be shorter than the proposed alias for it. I for
> > one don't see a significant benefit for adding a redundant synonym to
> > `Data.List` and are thus -1 on this.
> >
> > > singleton :: a -> [a]
> > > singleton x = [x]
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org <mailto:Libraries at haskell.org>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries <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 <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/20190812/196de467/attachment.html>

From andreas.abel at ifi.lmu.de  Mon Aug 12 19:57:51 2019
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Mon, 12 Aug 2019 21:57:51 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAH0njdsmq_iqAG+y2tz3TovOSAQkUPh-e_HndFQ8oJDmSAHQ=A@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
 <CAK7nUjjOOa_E_UbjV1fDirYKrizxsZf7CXaGmWMhMNHR62-qpg@mail.gmail.com>
 <CAH0njdsmq_iqAG+y2tz3TovOSAQkUPh-e_HndFQ8oJDmSAHQ=A@mail.gmail.com>
Message-ID: <011c0884-bbc7-7e2c-daca-f8fcbe96467c@ifi.lmu.de>

In the Agda code base there is a overloaded version of the singleton 
function.  Even more useful in its overloaded form!

   https://github.com/agda/agda/blob/master/src/full/Agda/Utils/Singleton.hs

As you can see here, singleton exists for many collection types already, 
it makes very much sense to have it also for List (and List.Nonempty).

+1 on Data.List.singleton, (but please not in the Prelude).

On 2019-08-12 20:36, Brent Yorgey wrote:
> At the risk of completely derailing the conversation, I have always 
> called this the "robot monkey operator".  I fail to see what is so 
> ninja-like about it.
> 
> Anyway, I think I am +1 on adding Data.List.singleton.
> 
> -Brent
> 
> On Mon, Aug 12, 2019, 12:35 PM Zemyla <zemyla at gmail.com 
> <mailto:zemyla at gmail.com>> wrote:
> 
>     I also like the ninja-robot operator, because it's visually
>     interesting and easy to search for.
> 
>     Also, if you're importing several libraries which already use
>     "singleton", then you have to use "List.singleton" every time, which
>     is far uglier to me.
> 
>     On Mon, Aug 12, 2019 at 12:03 PM Herbert Valerio Riedel
>     <hvriedel at gmail.com <mailto:hvriedel at gmail.com>> wrote:
>      >
>      > > - `(:[])`: Subjectively ugly.
>      >
>      > I consider "subjectively ugly" to be a non-technical and thus really
>      > weak argument to dismiss the list-idiomatic ninja-robot-operator
>     (:[])
>      > which also happens to be shorter than the proposed alias for it.
>     I for
>      > one don't see a significant benefit for adding a redundant synonym to
>      > `Data.List` and are thus -1 on this.
>      >
>      > > singleton :: a -> [a]
>      > > singleton x = [x]

From taylor at fausak.me  Mon Aug 12 21:16:38 2019
From: taylor at fausak.me (Taylor Fausak)
Date: Mon, 12 Aug 2019 17:16:38 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
Message-ID: <e1d9b1b2-c8e5-4591-bd91-cb9ff1b1debc@www.fastmail.com>

Coincidentally a related discussion came up on Reddit this morning:

https://np.reddit.com/r/haskell/comments/cpdlbr/how_would_i_go_about_printing_every_syllable/ewoplka/?context=1

On Mon, Aug 12, 2019, at 12:14 PM, Taylor Fausak wrote:
> I originally made this suggestion on GitLab, but I was told to make it 
> here instead.
> 
> https://gitlab.haskell.org/ghc/ghc/issues/17042
> 
> ---
> 
> # Add list singleton function
> 
> ## Motivation
> 
> Sometimes it is convenient to have a function to wrap an element in a 
> list. There are many ways to do this already, but none of them are as 
> clear as a separate monomorphic function.
> 
> - `pure`: Polymorphic, works for any `Functor`.
> - `pure @[]`: Noisy, requires `-XTypeApplications`.
> - `(: [])`: Subjectively ugly.
> - `(\x -> [x])`: Syntactically noisy.
> 
> This Twitter thread includes some additional commentary: 
> https://twitter.com/taylorfausak/status/1159264862247280640
> 
> ## Proposal
> 
> I would like to add a `singleton` function to `Data.List` that mirrors 
> the `singleton` function for other containers: 
> https://www.stackage.org/lts-14.0/hoogle?q=singleton
> 
> ``` hs
> singleton :: a -> [a]
> singleton x = [x]
> ```
> 
> Other Haskell-like languages include this function:
> 
> - PureScript: 
> https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.List#v:singleton
> - Elm: 
> https://package.elm-lang.org/packages/elm/core/latest/List#singleton
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

From tanuki at gmail.com  Mon Aug 12 22:36:10 2019
From: tanuki at gmail.com (Theodore Lief Gannon)
Date: Mon, 12 Aug 2019 15:36:10 -0700
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <C3BDE1D7-AB22-4A68-AA0A-3B5CD82173FC@gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
 <CAK7nUjjOOa_E_UbjV1fDirYKrizxsZf7CXaGmWMhMNHR62-qpg@mail.gmail.com>
 <CAH0njdsmq_iqAG+y2tz3TovOSAQkUPh-e_HndFQ8oJDmSAHQ=A@mail.gmail.com>
 <C3BDE1D7-AB22-4A68-AA0A-3B5CD82173FC@gmail.com>
Message-ID: <CAJoPsuDLpSWJOR60SmoaKJZvTFtJig8fPV4Z+_Hp6Di4J-_3vA@mail.gmail.com>

On Mon, Aug 12, 2019, 12:53 PM Andrew Lelechenko <
andrew.lelechenko at gmail.com> wrote:

> Adding singleton to Data.List is a breaking change, when
> Data.Map.singleton was exported unqualified.
>

Data.Map's documentation states that the entire module should be imported
qualified; this is not a reasonable counterargument.

RIO even takes the potentially-conflicting List functions out of Prelude,
and puts them in a RIO.List module which is also intended for qualified
import.

I'm +1. Personally I prefer `pure` and have TypeApplication enabled
globally; but that's not a universal style, and I see no real cost here
(though I agree it shouldn't be exposed in Prelude).

NonEmpty should get one too.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190812/948d3fda/attachment.html>

From eacameron at gmail.com  Tue Aug 13 00:07:07 2019
From: eacameron at gmail.com (Elliot Cameron)
Date: Mon, 12 Aug 2019 20:07:07 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAJoPsuDLpSWJOR60SmoaKJZvTFtJig8fPV4Z+_Hp6Di4J-_3vA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
 <CAK7nUjjOOa_E_UbjV1fDirYKrizxsZf7CXaGmWMhMNHR62-qpg@mail.gmail.com>
 <CAH0njdsmq_iqAG+y2tz3TovOSAQkUPh-e_HndFQ8oJDmSAHQ=A@mail.gmail.com>
 <C3BDE1D7-AB22-4A68-AA0A-3B5CD82173FC@gmail.com>
 <CAJoPsuDLpSWJOR60SmoaKJZvTFtJig8fPV4Z+_Hp6Di4J-_3vA@mail.gmail.com>
Message-ID: <CANPxu=wFgSv1pxFCwR+nbNgRNwEnkpwhK6+3MuVakKfP60xF6g@mail.gmail.com>

+1 and for NonEmpty. It's a common pattern for containers and I've always
been annoyed that List did not go with the flow.

On Mon, Aug 12, 2019 at 6:36 PM Theodore Lief Gannon <tanuki at gmail.com>
wrote:

> On Mon, Aug 12, 2019, 12:53 PM Andrew Lelechenko <
> andrew.lelechenko at gmail.com> wrote:
>
>> Adding singleton to Data.List is a breaking change, when
>> Data.Map.singleton was exported unqualified.
>>
>
> Data.Map's documentation states that the entire module should be imported
> qualified; this is not a reasonable counterargument.
>
> RIO even takes the potentially-conflicting List functions out of Prelude,
> and puts them in a RIO.List module which is also intended for qualified
> import.
>
> I'm +1. Personally I prefer `pure` and have TypeApplication enabled
> globally; but that's not a universal style, and I see no real cost here
> (though I agree it shouldn't be exposed in Prelude).
>
> NonEmpty should get one too.
>
>> _______________________________________________
> 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/20190812/20823fe5/attachment.html>

From josephcsible at gmail.com  Tue Aug 13 03:36:48 2019
From: josephcsible at gmail.com (Joseph C. Sible)
Date: Mon, 12 Aug 2019 23:36:48 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
Message-ID: <CABpewhHUDccg-4A2Tf5gw_QnsXq2z=MFnCNoj9o1bWbG3ZmhqQ@mail.gmail.com>

-1. AFAICT, "Polymorphic, works for any `Functor`" is an upside of
just using `pure`, not a downside. (Please correct me if I'm wrong,
and there is some disadvantage that I don't see.) Also, it looks like
for everything that has a `singleton`, it's something that isn't an
applicative functor, so they have them instead of `pure`, not in
addition to it.

Joseph C. Sible

On Mon, Aug 12, 2019 at 12:14 PM Taylor Fausak <taylor at fausak.me> wrote:
>
> I originally made this suggestion on GitLab, but I was told to make it here instead.
>
> https://gitlab.haskell.org/ghc/ghc/issues/17042
>
> ---
>
> # Add list singleton function
>
> ## Motivation
>
> Sometimes it is convenient to have a function to wrap an element in a list. There are many ways to do this already, but none of them are as clear as a separate monomorphic function.
>
> - `pure`: Polymorphic, works for any `Functor`.
> - `pure @[]`: Noisy, requires `-XTypeApplications`.
> - `(: [])`: Subjectively ugly.
> - `(\x -> [x])`: Syntactically noisy.
>
> This Twitter thread includes some additional commentary: https://twitter.com/taylorfausak/status/1159264862247280640
>
> ## Proposal
>
> I would like to add a `singleton` function to `Data.List` that mirrors the `singleton` function for other containers: https://www.stackage.org/lts-14.0/hoogle?q=singleton
>
> ``` hs
> singleton :: a -> [a]
> singleton x = [x]
> ```
>
> Other Haskell-like languages include this function:
>
> - PureScript: https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.List#v:singleton
> - Elm: https://package.elm-lang.org/packages/elm/core/latest/List#singleton
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From george at wils.online  Tue Aug 13 03:59:08 2019
From: george at wils.online (George Wilson)
Date: Tue, 13 Aug 2019 13:59:08 +1000
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CABpewhHUDccg-4A2Tf5gw_QnsXq2z=MFnCNoj9o1bWbG3ZmhqQ@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CABpewhHUDccg-4A2Tf5gw_QnsXq2z=MFnCNoj9o1bWbG3ZmhqQ@mail.gmail.com>
Message-ID: <CABzzMaw3Pmt1DXdGEfkDjfCwDA_XeT2txn5maE_aEgH6hQrfQg@mail.gmail.com>

Weak +1, I'd want it in NonEmpty too if it's going into List.

On Tue, 13 Aug 2019 at 13:37, Joseph C. Sible <josephcsible at gmail.com> wrote:
>
> -1. AFAICT, "Polymorphic, works for any `Functor`" is an upside of
> just using `pure`, not a downside. (Please correct me if I'm wrong,
> and there is some disadvantage that I don't see.) Also, it looks like
> for everything that has a `singleton`, it's something that isn't an
> applicative functor, so they have them instead of `pure`, not in
> addition to it.
>
> Joseph C. Sible
>
> On Mon, Aug 12, 2019 at 12:14 PM Taylor Fausak <taylor at fausak.me> wrote:
> >
> > I originally made this suggestion on GitLab, but I was told to make it here instead.
> >
> > https://gitlab.haskell.org/ghc/ghc/issues/17042
> >
> > ---
> >
> > # Add list singleton function
> >
> > ## Motivation
> >
> > Sometimes it is convenient to have a function to wrap an element in a list. There are many ways to do this already, but none of them are as clear as a separate monomorphic function.
> >
> > - `pure`: Polymorphic, works for any `Functor`.
> > - `pure @[]`: Noisy, requires `-XTypeApplications`.
> > - `(: [])`: Subjectively ugly.
> > - `(\x -> [x])`: Syntactically noisy.
> >
> > This Twitter thread includes some additional commentary: https://twitter.com/taylorfausak/status/1159264862247280640
> >
> > ## Proposal
> >
> > I would like to add a `singleton` function to `Data.List` that mirrors the `singleton` function for other containers: https://www.stackage.org/lts-14.0/hoogle?q=singleton
> >
> > ``` hs
> > singleton :: a -> [a]
> > singleton x = [x]
> > ```
> >
> > Other Haskell-like languages include this function:
> >
> > - PureScript: https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.List#v:singleton
> > - Elm: https://package.elm-lang.org/packages/elm/core/latest/List#singleton
> > _______________________________________________
> > 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 eacameron at gmail.com  Tue Aug 13 04:35:01 2019
From: eacameron at gmail.com (Elliot Cameron)
Date: Tue, 13 Aug 2019 00:35:01 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CABzzMaw3Pmt1DXdGEfkDjfCwDA_XeT2txn5maE_aEgH6hQrfQg@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CABpewhHUDccg-4A2Tf5gw_QnsXq2z=MFnCNoj9o1bWbG3ZmhqQ@mail.gmail.com>
 <CABzzMaw3Pmt1DXdGEfkDjfCwDA_XeT2txn5maE_aEgH6hQrfQg@mail.gmail.com>
Message-ID: <CANPxu=zHeP4FUpwi3wb9aPcoqaaY_d4PhdChnd1tUFF4RSJ6Dw@mail.gmail.com>

Seq is applicative and also has singleton. Some people like to avoid
polymorphism when the use case is clearly monomorphic (c.f. discussion
about map vs fmap).

I'd like to *point out* that Pointed is sort of the abstraction we really
want for this... But I still want a monomorphic function that doesn't delve
into Kmett dependencies.

On Mon, Aug 12, 2019 at 11:59 PM George Wilson <george at wils.online> wrote:

> Weak +1, I'd want it in NonEmpty too if it's going into List.
>
> On Tue, 13 Aug 2019 at 13:37, Joseph C. Sible <josephcsible at gmail.com>
> wrote:
> >
> > -1. AFAICT, "Polymorphic, works for any `Functor`" is an upside of
> > just using `pure`, not a downside. (Please correct me if I'm wrong,
> > and there is some disadvantage that I don't see.) Also, it looks like
> > for everything that has a `singleton`, it's something that isn't an
> > applicative functor, so they have them instead of `pure`, not in
> > addition to it.
> >
> > Joseph C. Sible
> >
> > On Mon, Aug 12, 2019 at 12:14 PM Taylor Fausak <taylor at fausak.me> wrote:
> > >
> > > I originally made this suggestion on GitLab, but I was told to make it
> here instead.
> > >
> > > https://gitlab.haskell.org/ghc/ghc/issues/17042
> > >
> > > ---
> > >
> > > # Add list singleton function
> > >
> > > ## Motivation
> > >
> > > Sometimes it is convenient to have a function to wrap an element in a
> list. There are many ways to do this already, but none of them are as clear
> as a separate monomorphic function.
> > >
> > > - `pure`: Polymorphic, works for any `Functor`.
> > > - `pure @[]`: Noisy, requires `-XTypeApplications`.
> > > - `(: [])`: Subjectively ugly.
> > > - `(\x -> [x])`: Syntactically noisy.
> > >
> > > This Twitter thread includes some additional commentary:
> https://twitter.com/taylorfausak/status/1159264862247280640
> > >
> > > ## Proposal
> > >
> > > I would like to add a `singleton` function to `Data.List` that mirrors
> the `singleton` function for other containers:
> https://www.stackage.org/lts-14.0/hoogle?q=singleton
> > >
> > > ``` hs
> > > singleton :: a -> [a]
> > > singleton x = [x]
> > > ```
> > >
> > > Other Haskell-like languages include this function:
> > >
> > > - PureScript:
> https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.List#v:singleton
> > > - Elm:
> https://package.elm-lang.org/packages/elm/core/latest/List#singleton
> > > _______________________________________________
> > > 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/20190813/b54b0183/attachment.html>

From matthewtpickering at gmail.com  Tue Aug 13 07:44:12 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 13 Aug 2019 09:44:12 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CANPxu=zHeP4FUpwi3wb9aPcoqaaY_d4PhdChnd1tUFF4RSJ6Dw@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CABpewhHUDccg-4A2Tf5gw_QnsXq2z=MFnCNoj9o1bWbG3ZmhqQ@mail.gmail.com>
 <CABzzMaw3Pmt1DXdGEfkDjfCwDA_XeT2txn5maE_aEgH6hQrfQg@mail.gmail.com>
 <CANPxu=zHeP4FUpwi3wb9aPcoqaaY_d4PhdChnd1tUFF4RSJ6Dw@mail.gmail.com>
Message-ID: <CALuQ0m82H+jAqhqB9YgJGn9BKyxDyWw9CPXf4=hHabqg-bdaRg@mail.gmail.com>

Clear +1 from me. I have defined this function many times.

The addition of a one line function does not prevent anyone from using
`pure` in their own code if they wish to obfuscate matters.

Cheers,

Matt

On Tue, Aug 13, 2019 at 6:35 AM Elliot Cameron <eacameron at gmail.com> wrote:
>
> Seq is applicative and also has singleton. Some people like to avoid polymorphism when the use case is clearly monomorphic (c.f. discussion about map vs fmap).
>
> I'd like to point out that Pointed is sort of the abstraction we really want for this... But I still want a monomorphic function that doesn't delve into Kmett dependencies.
>
> On Mon, Aug 12, 2019 at 11:59 PM George Wilson <george at wils.online> wrote:
>>
>> Weak +1, I'd want it in NonEmpty too if it's going into List.
>>
>> On Tue, 13 Aug 2019 at 13:37, Joseph C. Sible <josephcsible at gmail.com> wrote:
>> >
>> > -1. AFAICT, "Polymorphic, works for any `Functor`" is an upside of
>> > just using `pure`, not a downside. (Please correct me if I'm wrong,
>> > and there is some disadvantage that I don't see.) Also, it looks like
>> > for everything that has a `singleton`, it's something that isn't an
>> > applicative functor, so they have them instead of `pure`, not in
>> > addition to it.
>> >
>> > Joseph C. Sible
>> >
>> > On Mon, Aug 12, 2019 at 12:14 PM Taylor Fausak <taylor at fausak.me> wrote:
>> > >
>> > > I originally made this suggestion on GitLab, but I was told to make it here instead.
>> > >
>> > > https://gitlab.haskell.org/ghc/ghc/issues/17042
>> > >
>> > > ---
>> > >
>> > > # Add list singleton function
>> > >
>> > > ## Motivation
>> > >
>> > > Sometimes it is convenient to have a function to wrap an element in a list. There are many ways to do this already, but none of them are as clear as a separate monomorphic function.
>> > >
>> > > - `pure`: Polymorphic, works for any `Functor`.
>> > > - `pure @[]`: Noisy, requires `-XTypeApplications`.
>> > > - `(: [])`: Subjectively ugly.
>> > > - `(\x -> [x])`: Syntactically noisy.
>> > >
>> > > This Twitter thread includes some additional commentary: https://twitter.com/taylorfausak/status/1159264862247280640
>> > >
>> > > ## Proposal
>> > >
>> > > I would like to add a `singleton` function to `Data.List` that mirrors the `singleton` function for other containers: https://www.stackage.org/lts-14.0/hoogle?q=singleton
>> > >
>> > > ``` hs
>> > > singleton :: a -> [a]
>> > > singleton x = [x]
>> > > ```
>> > >
>> > > Other Haskell-like languages include this function:
>> > >
>> > > - PureScript: https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.List#v:singleton
>> > > - Elm: https://package.elm-lang.org/packages/elm/core/latest/List#singleton
>> > > _______________________________________________
>> > > 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From ekmett at gmail.com  Tue Aug 13 08:27:16 2019
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 13 Aug 2019 01:27:16 -0700
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CALuQ0m82H+jAqhqB9YgJGn9BKyxDyWw9CPXf4=hHabqg-bdaRg@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CABpewhHUDccg-4A2Tf5gw_QnsXq2z=MFnCNoj9o1bWbG3ZmhqQ@mail.gmail.com>
 <CABzzMaw3Pmt1DXdGEfkDjfCwDA_XeT2txn5maE_aEgH6hQrfQg@mail.gmail.com>
 <CANPxu=zHeP4FUpwi3wb9aPcoqaaY_d4PhdChnd1tUFF4RSJ6Dw@mail.gmail.com>
 <CALuQ0m82H+jAqhqB9YgJGn9BKyxDyWw9CPXf4=hHabqg-bdaRg@mail.gmail.com>
Message-ID: <CAJumaK_xeCMHOa7qeTK6buZ1YQhPbWj5tCJm9udN_frTPkSD+g@mail.gmail.com>

I'm a very weak personal -1 on this, just because pure already exists, is
half the length of the word in question, and adding 'singleton' will
introduce at least a few import conflicts, but I won't fight too hard for
my position.

-Edward

On Tue, Aug 13, 2019 at 12:44 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> Clear +1 from me. I have defined this function many times.
>
> The addition of a one line function does not prevent anyone from using
> `pure` in their own code if they wish to obfuscate matters.
>
> Cheers,
>
> Matt
>
> On Tue, Aug 13, 2019 at 6:35 AM Elliot Cameron <eacameron at gmail.com>
> wrote:
> >
> > Seq is applicative and also has singleton. Some people like to avoid
> polymorphism when the use case is clearly monomorphic (c.f. discussion
> about map vs fmap).
> >
> > I'd like to point out that Pointed is sort of the abstraction we really
> want for this... But I still want a monomorphic function that doesn't delve
> into Kmett dependencies.
> >
> > On Mon, Aug 12, 2019 at 11:59 PM George Wilson <george at wils.online>
> wrote:
> >>
> >> Weak +1, I'd want it in NonEmpty too if it's going into List.
> >>
> >> On Tue, 13 Aug 2019 at 13:37, Joseph C. Sible <josephcsible at gmail.com>
> wrote:
> >> >
> >> > -1. AFAICT, "Polymorphic, works for any `Functor`" is an upside of
> >> > just using `pure`, not a downside. (Please correct me if I'm wrong,
> >> > and there is some disadvantage that I don't see.) Also, it looks like
> >> > for everything that has a `singleton`, it's something that isn't an
> >> > applicative functor, so they have them instead of `pure`, not in
> >> > addition to it.
> >> >
> >> > Joseph C. Sible
> >> >
> >> > On Mon, Aug 12, 2019 at 12:14 PM Taylor Fausak <taylor at fausak.me>
> wrote:
> >> > >
> >> > > I originally made this suggestion on GitLab, but I was told to make
> it here instead.
> >> > >
> >> > > https://gitlab.haskell.org/ghc/ghc/issues/17042
> >> > >
> >> > > ---
> >> > >
> >> > > # Add list singleton function
> >> > >
> >> > > ## Motivation
> >> > >
> >> > > Sometimes it is convenient to have a function to wrap an element in
> a list. There are many ways to do this already, but none of them are as
> clear as a separate monomorphic function.
> >> > >
> >> > > - `pure`: Polymorphic, works for any `Functor`.
> >> > > - `pure @[]`: Noisy, requires `-XTypeApplications`.
> >> > > - `(: [])`: Subjectively ugly.
> >> > > - `(\x -> [x])`: Syntactically noisy.
> >> > >
> >> > > This Twitter thread includes some additional commentary:
> https://twitter.com/taylorfausak/status/1159264862247280640
> >> > >
> >> > > ## Proposal
> >> > >
> >> > > I would like to add a `singleton` function to `Data.List` that
> mirrors the `singleton` function for other containers:
> https://www.stackage.org/lts-14.0/hoogle?q=singleton
> >> > >
> >> > > ``` hs
> >> > > singleton :: a -> [a]
> >> > > singleton x = [x]
> >> > > ```
> >> > >
> >> > > Other Haskell-like languages include this function:
> >> > >
> >> > > - PureScript:
> https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.List#v:singleton
> >> > > - Elm:
> https://package.elm-lang.org/packages/elm/core/latest/List#singleton
> >> > > _______________________________________________
> >> > > 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
> >
> > _______________________________________________
> > 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/20190813/a518b1f9/attachment.html>

From tikhon at jelv.is  Tue Aug 13 08:33:23 2019
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Tue, 13 Aug 2019 10:33:23 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CALuQ0m82H+jAqhqB9YgJGn9BKyxDyWw9CPXf4=hHabqg-bdaRg@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CABpewhHUDccg-4A2Tf5gw_QnsXq2z=MFnCNoj9o1bWbG3ZmhqQ@mail.gmail.com>
 <CABzzMaw3Pmt1DXdGEfkDjfCwDA_XeT2txn5maE_aEgH6hQrfQg@mail.gmail.com>
 <CANPxu=zHeP4FUpwi3wb9aPcoqaaY_d4PhdChnd1tUFF4RSJ6Dw@mail.gmail.com>
 <CALuQ0m82H+jAqhqB9YgJGn9BKyxDyWw9CPXf4=hHabqg-bdaRg@mail.gmail.com>
Message-ID: <CAJN5CVK3YoAKyGyufUR4HR3P-tkM_N5T19aXYF+Ciev=dLhhFQ@mail.gmail.com>

Another advantage to having an explicit singleton function is
discoverablity. I distinctly remember looking for exactly this function
when I was a beginner and being confused because it didn't seem to exist.

Idioms like (:[]) are not intuitive at all. Polymorphic functions like pure
require you to know that list is an Applicative, which you won't learn
right away. Even if your have learned about Applicatives, it's easy to miss
that connection when you're thinking about lists as a data structure rather
than as a control structure, which is exactly the scenario I expect people
to use a singleton function.

On Tue, Aug 13, 2019, 09:44 Matthew Pickering <matthewtpickering at gmail.com>
wrote:

> Clear +1 from me. I have defined this function many times.
>
> The addition of a one line function does not prevent anyone from using
> `pure` in their own code if they wish to obfuscate matters.
>
> Cheers,
>
> Matt
>
> On Tue, Aug 13, 2019 at 6:35 AM Elliot Cameron <eacameron at gmail.com>
> wrote:
> >
> > Seq is applicative and also has singleton. Some people like to avoid
> polymorphism when the use case is clearly monomorphic (c.f. discussion
> about map vs fmap).
> >
> > I'd like to point out that Pointed is sort of the abstraction we really
> want for this... But I still want a monomorphic function that doesn't delve
> into Kmett dependencies.
> >
> > On Mon, Aug 12, 2019 at 11:59 PM George Wilson <george at wils.online>
> wrote:
> >>
> >> Weak +1, I'd want it in NonEmpty too if it's going into List.
> >>
> >> On Tue, 13 Aug 2019 at 13:37, Joseph C. Sible <josephcsible at gmail.com>
> wrote:
> >> >
> >> > -1. AFAICT, "Polymorphic, works for any `Functor`" is an upside of
> >> > just using `pure`, not a downside. (Please correct me if I'm wrong,
> >> > and there is some disadvantage that I don't see.) Also, it looks like
> >> > for everything that has a `singleton`, it's something that isn't an
> >> > applicative functor, so they have them instead of `pure`, not in
> >> > addition to it.
> >> >
> >> > Joseph C. Sible
> >> >
> >> > On Mon, Aug 12, 2019 at 12:14 PM Taylor Fausak <taylor at fausak.me>
> wrote:
> >> > >
> >> > > I originally made this suggestion on GitLab, but I was told to make
> it here instead.
> >> > >
> >> > > https://gitlab.haskell.org/ghc/ghc/issues/17042
> >> > >
> >> > > ---
> >> > >
> >> > > # Add list singleton function
> >> > >
> >> > > ## Motivation
> >> > >
> >> > > Sometimes it is convenient to have a function to wrap an element in
> a list. There are many ways to do this already, but none of them are as
> clear as a separate monomorphic function.
> >> > >
> >> > > - `pure`: Polymorphic, works for any `Functor`.
> >> > > - `pure @[]`: Noisy, requires `-XTypeApplications`.
> >> > > - `(: [])`: Subjectively ugly.
> >> > > - `(\x -> [x])`: Syntactically noisy.
> >> > >
> >> > > This Twitter thread includes some additional commentary:
> https://twitter.com/taylorfausak/status/1159264862247280640
> >> > >
> >> > > ## Proposal
> >> > >
> >> > > I would like to add a `singleton` function to `Data.List` that
> mirrors the `singleton` function for other containers:
> https://www.stackage.org/lts-14.0/hoogle?q=singleton
> >> > >
> >> > > ``` hs
> >> > > singleton :: a -> [a]
> >> > > singleton x = [x]
> >> > > ```
> >> > >
> >> > > Other Haskell-like languages include this function:
> >> > >
> >> > > - PureScript:
> https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.List#v:singleton
> >> > > - Elm:
> https://package.elm-lang.org/packages/elm/core/latest/List#singleton
> >> > > _______________________________________________
> >> > > 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
> >
> > _______________________________________________
> > 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/20190813/993a4c44/attachment.html>

From jon.fairbairn at cl.cam.ac.uk  Tue Aug 13 08:49:22 2019
From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn)
Date: Tue, 13 Aug 2019 09:49:22 +0100
Subject: Proposal: Add singleton function to Data.List module
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CABpewhHUDccg-4A2Tf5gw_QnsXq2z=MFnCNoj9o1bWbG3ZmhqQ@mail.gmail.com>
 <CABzzMaw3Pmt1DXdGEfkDjfCwDA_XeT2txn5maE_aEgH6hQrfQg@mail.gmail.com>
 <CANPxu=zHeP4FUpwi3wb9aPcoqaaY_d4PhdChnd1tUFF4RSJ6Dw@mail.gmail.com>
 <CALuQ0m82H+jAqhqB9YgJGn9BKyxDyWw9CPXf4=hHabqg-bdaRg@mail.gmail.com>
 <CAJN5CVK3YoAKyGyufUR4HR3P-tkM_N5T19aXYF+Ciev=dLhhFQ@mail.gmail.com>
Message-ID: <yplrzhkdlab1.fsf@calligramme.charmers>

Tikhon Jelvis <tikhon at jelv.is> writes:

> Idioms like (:[]) are not intuitive at all.

Can you explain that? Once one knows that all infix operators
can be used in sections (+1), (++"foo"), etc, that notation
should be obvious, both in reading and writing. It’s much better
to use ideas that are uniformly usable throughout the language
and can be learned once than to have to learn numerous specific
words.

I’m -1 on the proposal, obviously.

-- 
Jón Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk


From tikhon at jelv.is  Tue Aug 13 09:10:26 2019
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Tue, 13 Aug 2019 11:10:26 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <yplrzhkdlab1.fsf@calligramme.charmers>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CABpewhHUDccg-4A2Tf5gw_QnsXq2z=MFnCNoj9o1bWbG3ZmhqQ@mail.gmail.com>
 <CABzzMaw3Pmt1DXdGEfkDjfCwDA_XeT2txn5maE_aEgH6hQrfQg@mail.gmail.com>
 <CANPxu=zHeP4FUpwi3wb9aPcoqaaY_d4PhdChnd1tUFF4RSJ6Dw@mail.gmail.com>
 <CALuQ0m82H+jAqhqB9YgJGn9BKyxDyWw9CPXf4=hHabqg-bdaRg@mail.gmail.com>
 <CAJN5CVK3YoAKyGyufUR4HR3P-tkM_N5T19aXYF+Ciev=dLhhFQ@mail.gmail.com>
 <yplrzhkdlab1.fsf@calligramme.charmers>
Message-ID: <CAJN5CVJn6fvu5f5=MaG8LeLB4k8HBOe8Ai+kLanRM7nL7mfFDg@mail.gmail.com>

The reason it's particularly unintuitive for lists is that we almost never
explicitly construct lists using : and []. Sections like (+ 1) or (++
"Foo") reflect expressions like x + 1 and str ++ "Foo", but you simply
never see x : [] in the wild. (In fact, in code review, I would always
expect that to be rewritten as [x].)

In turn, this means that (:[]) doesn't convey my intentions as directly as
possible. I want to build a list that contains a single element x, which I
usually think of as [x]; the fact that I do this by consing x with an empty
list is an implementation detail.

More generally, lists merit a special case because list notation is
*already* a special case, and we can't do anything about that at this point!


On Tue, Aug 13, 2019, 10:49 Jon Fairbairn <jon.fairbairn at cl.cam.ac.uk>
wrote:

> Tikhon Jelvis <tikhon at jelv.is> writes:
>
> > Idioms like (:[]) are not intuitive at all.
>
> Can you explain that? Once one knows that all infix operators
> can be used in sections (+1), (++"foo"), etc, that notation
> should be obvious, both in reading and writing. It’s much better
> to use ideas that are uniformly usable throughout the language
> and can be learned once than to have to learn numerous specific
> words.
>
> I’m -1 on the proposal, obviously.
>
> --
> Jón Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk
>
> _______________________________________________
> 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/20190813/440da477/attachment.html>

From david.feuer at gmail.com  Tue Aug 13 09:11:04 2019
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 13 Aug 2019 16:11:04 +0700
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
Message-ID: <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>

I'm moderately +1 for consistency, and for NonEmpty as well. There is a
concept here: create a container containing exactly one value. As Tikhon
indicates, this is a different concept from pure. For example, a singleton
ZipList has one element, while a pure one has infinitely many elements.

On Mon, Aug 12, 2019, 11:14 PM Taylor Fausak <taylor at fausak.me> wrote:

> I originally made this suggestion on GitLab, but I was told to make it
> here instead.
>
> https://gitlab.haskell.org/ghc/ghc/issues/17042
>
> ---
>
> # Add list singleton function
>
> ## Motivation
>
> Sometimes it is convenient to have a function to wrap an element in a
> list. There are many ways to do this already, but none of them are as clear
> as a separate monomorphic function.
>
> - `pure`: Polymorphic, works for any `Functor`.
> - `pure @[]`: Noisy, requires `-XTypeApplications`.
> - `(: [])`: Subjectively ugly.
> - `(\x -> [x])`: Syntactically noisy.
>
> This Twitter thread includes some additional commentary:
> https://twitter.com/taylorfausak/status/1159264862247280640
>
> ## Proposal
>
> I would like to add a `singleton` function to `Data.List` that mirrors the
> `singleton` function for other containers:
> https://www.stackage.org/lts-14.0/hoogle?q=singleton
>
> ``` hs
> singleton :: a -> [a]
> singleton x = [x]
> ```
>
> Other Haskell-like languages include this function:
>
> - PureScript:
> https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.List#v:singleton
> - Elm:
> https://package.elm-lang.org/packages/elm/core/latest/List#singleton
> _______________________________________________
> 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/20190813/f07703ae/attachment.html>

From zemyla at gmail.com  Tue Aug 13 16:24:09 2019
From: zemyla at gmail.com (Zemyla)
Date: Tue, 13 Aug 2019 11:24:09 -0500
Subject: indexM or (!?)-style accessor for arrays?
Message-ID: <CAK7nUjhFWz4Rx-oV2B_M0Qc-TzL41nquDWRJnaxKUEz3noBJ=A@mail.gmail.com>

This is an issue I originally proposed on GHC Trac, but I'm posting it
here because (I think) the Data.Array package is under the purview of
the Libraries committee.

The vector package has indexM and its cousins so that a user can be
strict in the array without necessarily being strict in the value
retrieved from that array. Arrays don't have that sort of thing,
meaning that anything you do that takes an array will necessarily
leave references to the array unless you force the whole thing, and
that's not only inefficient, it's untenable for general libraries.

What I'm thinking is that the IArray class should have a function like

unsafeAtM :: (Array a e, Ix i, Applicative m) => a i e -> Int -> m e

For compatibility with older code that wouldn't necessarily define
this but would define unsafeAt, we'd have the default implementation

unsafeAtM a !n = pure (unsafeAt a n)

Also, you could have unsafeAt defined in terms of unsafeAtM, so the
minimal implementation could require only one of them:

unsafeAt = (coerce :: (a i e -> Int -> Identity e) -> a i e -> Int ->
e) unsafeAtM

Also, (!?) would be a "safe" indexing tool for arrays, which would
incidentally also force the array without forcing the value inside.
You would have

(!?) :: (Array a e, Ix i) => a i e -> i -> Maybe e
(!?) a e = case bounds a of
  p@(l, u) -> case inRange p e of
    True -> unsafeAtM arr $ unsafeIndex p e
    False -> Nothing

From ekmett at gmail.com  Tue Aug 13 16:28:59 2019
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 13 Aug 2019 09:28:59 -0700
Subject: indexM or (!?)-style accessor for arrays?
In-Reply-To: <CAK7nUjhFWz4Rx-oV2B_M0Qc-TzL41nquDWRJnaxKUEz3noBJ=A@mail.gmail.com>
References: <CAK7nUjhFWz4Rx-oV2B_M0Qc-TzL41nquDWRJnaxKUEz3noBJ=A@mail.gmail.com>
Message-ID: <CAJumaK9UHsaLShtits7jUOxOrq0953s5W0ZtX1Dj26W0-bc=gg@mail.gmail.com>

I'm pretty strongly +1 on this, assuming someone is willing to chase down
all the implementation issues, as the current API doesn't really allow for
efficient usage.

I'm not sure that Applicative is strong enough to give the desired
behavior, though.

e.g. to write a strict fmap (<$!>) you need Monad.

-Edward

On Tue, Aug 13, 2019 at 9:24 AM Zemyla <zemyla at gmail.com> wrote:

> This is an issue I originally proposed on GHC Trac, but I'm posting it
> here because (I think) the Data.Array package is under the purview of
> the Libraries committee.
>
> The vector package has indexM and its cousins so that a user can be
> strict in the array without necessarily being strict in the value
> retrieved from that array. Arrays don't have that sort of thing,
> meaning that anything you do that takes an array will necessarily
> leave references to the array unless you force the whole thing, and
> that's not only inefficient, it's untenable for general libraries.
>
> What I'm thinking is that the IArray class should have a function like
>
> unsafeAtM :: (Array a e, Ix i, Applicative m) => a i e -> Int -> m e
>
> For compatibility with older code that wouldn't necessarily define
> this but would define unsafeAt, we'd have the default implementation
>
> unsafeAtM a !n = pure (unsafeAt a n)
>
> Also, you could have unsafeAt defined in terms of unsafeAtM, so the
> minimal implementation could require only one of them:
>
> unsafeAt = (coerce :: (a i e -> Int -> Identity e) -> a i e -> Int ->
> e) unsafeAtM
>
> Also, (!?) would be a "safe" indexing tool for arrays, which would
> incidentally also force the array without forcing the value inside.
> You would have
>
> (!?) :: (Array a e, Ix i) => a i e -> i -> Maybe e
> (!?) a e = case bounds a of
>   p@(l, u) -> case inRange p e of
>     True -> unsafeAtM arr $ unsafeIndex p e
>     False -> Nothing
> _______________________________________________
> 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/20190813/c44d2ca2/attachment.html>

From zemyla at gmail.com  Tue Aug 13 17:33:15 2019
From: zemyla at gmail.com (Zemyla)
Date: Tue, 13 Aug 2019 12:33:15 -0500
Subject: indexM or (!?)-style accessor for arrays?
In-Reply-To: <CAJumaK9UHsaLShtits7jUOxOrq0953s5W0ZtX1Dj26W0-bc=gg@mail.gmail.com>
References: <CAK7nUjhFWz4Rx-oV2B_M0Qc-TzL41nquDWRJnaxKUEz3noBJ=A@mail.gmail.com>
 <CAJumaK9UHsaLShtits7jUOxOrq0953s5W0ZtX1Dj26W0-bc=gg@mail.gmail.com>
Message-ID: <CAK7nUjh6pNJYXqi0JgWyE_RoEw-vRpeo4BKeV4S=q=rSoLHBPQ@mail.gmail.com>

Well, the reason I say Applicative is because the only method from
Monad which is used is return, which is the same as pure in
Applicative. I'm preparing for when the "Monad of no return" proposal
gets implemented.

On Tue, Aug 13, 2019 at 11:29 AM Edward Kmett <ekmett at gmail.com> wrote:
>
> I'm pretty strongly +1 on this, assuming someone is willing to chase down all the implementation issues, as the current API doesn't really allow for efficient usage.
>
> I'm not sure that Applicative is strong enough to give the desired behavior, though.
>
> e.g. to write a strict fmap (<$!>) you need Monad.
>
> -Edward
>
> On Tue, Aug 13, 2019 at 9:24 AM Zemyla <zemyla at gmail.com> wrote:
>>
>> This is an issue I originally proposed on GHC Trac, but I'm posting it
>> here because (I think) the Data.Array package is under the purview of
>> the Libraries committee.
>>
>> The vector package has indexM and its cousins so that a user can be
>> strict in the array without necessarily being strict in the value
>> retrieved from that array. Arrays don't have that sort of thing,
>> meaning that anything you do that takes an array will necessarily
>> leave references to the array unless you force the whole thing, and
>> that's not only inefficient, it's untenable for general libraries.
>>
>> What I'm thinking is that the IArray class should have a function like
>>
>> unsafeAtM :: (Array a e, Ix i, Applicative m) => a i e -> Int -> m e
>>
>> For compatibility with older code that wouldn't necessarily define
>> this but would define unsafeAt, we'd have the default implementation
>>
>> unsafeAtM a !n = pure (unsafeAt a n)
>>
>> Also, you could have unsafeAt defined in terms of unsafeAtM, so the
>> minimal implementation could require only one of them:
>>
>> unsafeAt = (coerce :: (a i e -> Int -> Identity e) -> a i e -> Int ->
>> e) unsafeAtM
>>
>> Also, (!?) would be a "safe" indexing tool for arrays, which would
>> incidentally also force the array without forcing the value inside.
>> You would have
>>
>> (!?) :: (Array a e, Ix i) => a i e -> i -> Maybe e
>> (!?) a e = case bounds a of
>>   p@(l, u) -> case inRange p e of
>>     True -> unsafeAtM arr $ unsafeIndex p e
>>     False -> Nothing
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From ekmett at gmail.com  Tue Aug 13 17:47:03 2019
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 13 Aug 2019 10:47:03 -0700
Subject: indexM or (!?)-style accessor for arrays?
In-Reply-To: <CAK7nUjh6pNJYXqi0JgWyE_RoEw-vRpeo4BKeV4S=q=rSoLHBPQ@mail.gmail.com>
References: <CAK7nUjhFWz4Rx-oV2B_M0Qc-TzL41nquDWRJnaxKUEz3noBJ=A@mail.gmail.com>
 <CAJumaK9UHsaLShtits7jUOxOrq0953s5W0ZtX1Dj26W0-bc=gg@mail.gmail.com>
 <CAK7nUjh6pNJYXqi0JgWyE_RoEw-vRpeo4BKeV4S=q=rSoLHBPQ@mail.gmail.com>
Message-ID: <CAJumaK8tUS_9izus8k4S5E_0iPAvq-OfH5U=Ey4yGORpr+QZdA@mail.gmail.com>

I'd for some reason assumed that vector's indexM actually combined values
for the Unboxed case, but it looks like _it_ should be generalized to
Applicative, too.

-Edwrd

On Tue, Aug 13, 2019 at 10:33 AM Zemyla <zemyla at gmail.com> wrote:

> Well, the reason I say Applicative is because the only method from
> Monad which is used is return, which is the same as pure in
> Applicative. I'm preparing for when the "Monad of no return" proposal
> gets implemented.
>
> On Tue, Aug 13, 2019 at 11:29 AM Edward Kmett <ekmett at gmail.com> wrote:
> >
> > I'm pretty strongly +1 on this, assuming someone is willing to chase
> down all the implementation issues, as the current API doesn't really allow
> for efficient usage.
> >
> > I'm not sure that Applicative is strong enough to give the desired
> behavior, though.
> >
> > e.g. to write a strict fmap (<$!>) you need Monad.
> >
> > -Edward
> >
> > On Tue, Aug 13, 2019 at 9:24 AM Zemyla <zemyla at gmail.com> wrote:
> >>
> >> This is an issue I originally proposed on GHC Trac, but I'm posting it
> >> here because (I think) the Data.Array package is under the purview of
> >> the Libraries committee.
> >>
> >> The vector package has indexM and its cousins so that a user can be
> >> strict in the array without necessarily being strict in the value
> >> retrieved from that array. Arrays don't have that sort of thing,
> >> meaning that anything you do that takes an array will necessarily
> >> leave references to the array unless you force the whole thing, and
> >> that's not only inefficient, it's untenable for general libraries.
> >>
> >> What I'm thinking is that the IArray class should have a function like
> >>
> >> unsafeAtM :: (Array a e, Ix i, Applicative m) => a i e -> Int -> m e
> >>
> >> For compatibility with older code that wouldn't necessarily define
> >> this but would define unsafeAt, we'd have the default implementation
> >>
> >> unsafeAtM a !n = pure (unsafeAt a n)
> >>
> >> Also, you could have unsafeAt defined in terms of unsafeAtM, so the
> >> minimal implementation could require only one of them:
> >>
> >> unsafeAt = (coerce :: (a i e -> Int -> Identity e) -> a i e -> Int ->
> >> e) unsafeAtM
> >>
> >> Also, (!?) would be a "safe" indexing tool for arrays, which would
> >> incidentally also force the array without forcing the value inside.
> >> You would have
> >>
> >> (!?) :: (Array a e, Ix i) => a i e -> i -> Maybe e
> >> (!?) a e = case bounds a of
> >>   p@(l, u) -> case inRange p e of
> >>     True -> unsafeAtM arr $ unsafeIndex p e
> >>     False -> Nothing
> >> _______________________________________________
> >> 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/20190813/2d91ec07/attachment.html>

From andrew.thaddeus at gmail.com  Tue Aug 13 18:44:45 2019
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Tue, 13 Aug 2019 14:44:45 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
Message-ID: <CABNC7eOHsb=a60v_v=GS0MrKjemPAt4tfANrBrKPbc_nM+A6gA@mail.gmail.com>

I'm +1 on this. I've defined this function in my own code before. Using
pure instead leads to harder-to-read code for future me and for
collaborators. It also leads to worse type errors in the event that I mess
something up.

On Tue, Aug 13, 2019 at 5:11 AM David Feuer <david.feuer at gmail.com> wrote:

> I'm moderately +1 for consistency, and for NonEmpty as well. There is a
> concept here: create a container containing exactly one value. As Tikhon
> indicates, this is a different concept from pure. For example, a singleton
> ZipList has one element, while a pure one has infinitely many elements.
>
> On Mon, Aug 12, 2019, 11:14 PM Taylor Fausak <taylor at fausak.me> wrote:
>
>> I originally made this suggestion on GitLab, but I was told to make it
>> here instead.
>>
>> https://gitlab.haskell.org/ghc/ghc/issues/17042
>>
>> ---
>>
>> # Add list singleton function
>>
>> ## Motivation
>>
>> Sometimes it is convenient to have a function to wrap an element in a
>> list. There are many ways to do this already, but none of them are as clear
>> as a separate monomorphic function.
>>
>> - `pure`: Polymorphic, works for any `Functor`.
>> - `pure @[]`: Noisy, requires `-XTypeApplications`.
>> - `(: [])`: Subjectively ugly.
>> - `(\x -> [x])`: Syntactically noisy.
>>
>> This Twitter thread includes some additional commentary:
>> https://twitter.com/taylorfausak/status/1159264862247280640
>>
>> ## Proposal
>>
>> I would like to add a `singleton` function to `Data.List` that mirrors
>> the `singleton` function for other containers:
>> https://www.stackage.org/lts-14.0/hoogle?q=singleton
>>
>> ``` hs
>> singleton :: a -> [a]
>> singleton x = [x]
>> ```
>>
>> Other Haskell-like languages include this function:
>>
>> - PureScript:
>> https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.List#v:singleton
>> - Elm:
>> https://package.elm-lang.org/packages/elm/core/latest/List#singleton
>> _______________________________________________
>> 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
>


-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190813/815f02f0/attachment.html>

From zemyla at gmail.com  Tue Aug 13 19:31:23 2019
From: zemyla at gmail.com (Zemyla)
Date: Tue, 13 Aug 2019 14:31:23 -0500
Subject: indexM or (!?)-style accessor for arrays?
In-Reply-To: <CAJumaK8tUS_9izus8k4S5E_0iPAvq-OfH5U=Ey4yGORpr+QZdA@mail.gmail.com>
References: <CAK7nUjhFWz4Rx-oV2B_M0Qc-TzL41nquDWRJnaxKUEz3noBJ=A@mail.gmail.com>
 <CAJumaK9UHsaLShtits7jUOxOrq0953s5W0ZtX1Dj26W0-bc=gg@mail.gmail.com>
 <CAK7nUjh6pNJYXqi0JgWyE_RoEw-vRpeo4BKeV4S=q=rSoLHBPQ@mail.gmail.com>
 <CAJumaK8tUS_9izus8k4S5E_0iPAvq-OfH5U=Ey4yGORpr+QZdA@mail.gmail.com>
Message-ID: <CAK7nUjh0ert_L0AZu4xpGEGs5okKuWCNkS8XazLawnMOXGG0hg@mail.gmail.com>

Also, even if the base implementation of indexM were Monad-only, you could do

indexA :: (Applicative m, Array a e, Ix i) => a i e -> i -> m e
indexA a e = runCont (indexM a e) pure

to pass it to an Applicative.

On Tue, Aug 13, 2019 at 12:47 PM Edward Kmett <ekmett at gmail.com> wrote:
>
> I'd for some reason assumed that vector's indexM actually combined values for the Unboxed case, but it looks like _it_ should be generalized to Applicative, too.
>
> -Edwrd
>
> On Tue, Aug 13, 2019 at 10:33 AM Zemyla <zemyla at gmail.com> wrote:
>>
>> Well, the reason I say Applicative is because the only method from
>> Monad which is used is return, which is the same as pure in
>> Applicative. I'm preparing for when the "Monad of no return" proposal
>> gets implemented.
>>
>> On Tue, Aug 13, 2019 at 11:29 AM Edward Kmett <ekmett at gmail.com> wrote:
>> >
>> > I'm pretty strongly +1 on this, assuming someone is willing to chase down all the implementation issues, as the current API doesn't really allow for efficient usage.
>> >
>> > I'm not sure that Applicative is strong enough to give the desired behavior, though.
>> >
>> > e.g. to write a strict fmap (<$!>) you need Monad.
>> >
>> > -Edward
>> >
>> > On Tue, Aug 13, 2019 at 9:24 AM Zemyla <zemyla at gmail.com> wrote:
>> >>
>> >> This is an issue I originally proposed on GHC Trac, but I'm posting it
>> >> here because (I think) the Data.Array package is under the purview of
>> >> the Libraries committee.
>> >>
>> >> The vector package has indexM and its cousins so that a user can be
>> >> strict in the array without necessarily being strict in the value
>> >> retrieved from that array. Arrays don't have that sort of thing,
>> >> meaning that anything you do that takes an array will necessarily
>> >> leave references to the array unless you force the whole thing, and
>> >> that's not only inefficient, it's untenable for general libraries.
>> >>
>> >> What I'm thinking is that the IArray class should have a function like
>> >>
>> >> unsafeAtM :: (Array a e, Ix i, Applicative m) => a i e -> Int -> m e
>> >>
>> >> For compatibility with older code that wouldn't necessarily define
>> >> this but would define unsafeAt, we'd have the default implementation
>> >>
>> >> unsafeAtM a !n = pure (unsafeAt a n)
>> >>
>> >> Also, you could have unsafeAt defined in terms of unsafeAtM, so the
>> >> minimal implementation could require only one of them:
>> >>
>> >> unsafeAt = (coerce :: (a i e -> Int -> Identity e) -> a i e -> Int ->
>> >> e) unsafeAtM
>> >>
>> >> Also, (!?) would be a "safe" indexing tool for arrays, which would
>> >> incidentally also force the array without forcing the value inside.
>> >> You would have
>> >>
>> >> (!?) :: (Array a e, Ix i) => a i e -> i -> Maybe e
>> >> (!?) a e = case bounds a of
>> >>   p@(l, u) -> case inRange p e of
>> >>     True -> unsafeAtM arr $ unsafeIndex p e
>> >>     False -> Nothing
>> >> _______________________________________________
>> >> Libraries mailing list
>> >> Libraries at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From hvriedel at gmail.com  Tue Aug 13 22:13:17 2019
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Wed, 14 Aug 2019 00:13:17 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
Message-ID: <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>

>  There is a concept here: create a container containing exactly one value. As Tikhon indicates, this is a different concept from pure.

Fwiw, if you actually want a possibly meaningful/lawful reification of
the very specific "create any container containing exactly one item"
concept then an obvious approach would be to base it on the existing
(IMO under-appreciated) 'IsList' abstraction; in other words basically
something like

    singleton :: IsList l => Item l -> l
    singleton = fromListN 1 . (:[])

which could either be a method of `IsList` (with the default impl
above and an obvious lawful relationship to `fromList`/`toList`) or
just be a top-level binding exported from "GHC.List" and/or "GHC.Exts"
(which aren't governed by the Haskell Library Report and thus have a
lower barrier to entry).

From parsonsmatt at gmail.com  Tue Aug 13 22:25:58 2019
From: parsonsmatt at gmail.com (Matt)
Date: Tue, 13 Aug 2019 16:25:58 -0600
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
Message-ID: <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>

The point is to create a monomorphic variant that avoids the problems with
the polymorphic `pure` and would be consistent with the other
container-types. A polymorphic `singleton` would be useful, but - in the
same way that `Map.fromLIst` and `Set.fromList` are (usefully!) monomorphic
despite equivalent `IsList` methods, we'd still want to have a concrete
`List.singleton :: a -> [a]`.

I see a lot of "Why isn't `pure` good enough here?", so I'd like to
reiterate that `pure` has issues:

- It's not immediately+syntactically obvious what's being created.
List.singleton is unambiguous to read.
- Polymorphism can cause unintended changes to behavior if GHC infers a
different type than you expect. Consider `length (1,2)` confusion, `fmap
(+1) (Left 1)` - while these have an obviously correct instance, it can
still be confusing and yield potentially incorrect results.
- Monomorphic functions can often be very useful to inform GHC about a
specific type you want to fix and allow the rest of inference to work
around. Typed-holes provide *much* better information when you have
concrete types rather than constrained polymorphic types.
- Finally, monomorphic functions can be used to prevent ambiguous type
errors in the presence of OverloadedLists and OverloadedStrings, especially
when every other method in the chain is written on Foldable or similar
constraints.

Matt Parsons


On Tue, Aug 13, 2019 at 4:13 PM Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> >  There is a concept here: create a container containing exactly one
> value. As Tikhon indicates, this is a different concept from pure.
>
> Fwiw, if you actually want a possibly meaningful/lawful reification of
> the very specific "create any container containing exactly one item"
> concept then an obvious approach would be to base it on the existing
> (IMO under-appreciated) 'IsList' abstraction; in other words basically
> something like
>
>     singleton :: IsList l => Item l -> l
>     singleton = fromListN 1 . (:[])
>
> which could either be a method of `IsList` (with the default impl
> above and an obvious lawful relationship to `fromList`/`toList`) or
> just be a top-level binding exported from "GHC.List" and/or "GHC.Exts"
> (which aren't governed by the Haskell Library Report and thus have a
> lower barrier to entry).
> _______________________________________________
> 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/20190813/3141d3a1/attachment.html>

From hvriedel at gmail.com  Tue Aug 13 22:56:18 2019
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Wed, 14 Aug 2019 00:56:18 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
Message-ID: <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>

> The point is to create a monomorphic variant [...]

But we already have at least two monomorphic variants to express this
with Haskell's concise native syntax and vocabulary which has by
design a preferential treatment of lists (it was considered even more
important than type-sigs so that we got the `:` cons operator for
lists and the `::` for type-sig annotations) -- so let's not try to
fight Haskell's core idioms by hiding them behind some trivial
additional redundant synonyms! I still fail to see the actual
*technical* problem being solved by the original proposal asking to
add yet another, wordy way to construct single-item-lists.

From parsonsmatt at gmail.com  Tue Aug 13 23:20:20 2019
From: parsonsmatt at gmail.com (Matt)
Date: Tue, 13 Aug 2019 17:20:20 -0600
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
Message-ID: <CA+4qU94-QvzS0O9TyHPTQxw37NfN732bR3cJk_f1TN2zoMOR9Q@mail.gmail.com>

`(\x -> [x])` has the same polymorphism problem in the context of
`OverloadedLists` as `pure`.

`(:[])` is also unsatisfactory. To parse it properly, you need to:

- Know that `:` is only allowed as an operator to prefix data constructors,
- Know that `[]` are not legal operator characters,
- Infer that you're intended to insert a space between the `:` and `[]` to
get `(: [])`
- Recognize it as an operator section being used prefix as a normal function

I'm neither an expert nor a lifelong Haskeller, but I have been writing it
in some professional capacity for four years now, and the operator section
trips me up. I can't imagine less experienced folks find it easy or
intuitive. You can't even search for it on hoogle:
https://hoogle.haskell.org/?hoogle=(%3A%5B%5D)

Is `(:[])` a core idiom? I never see it in work code and I've never seen it
in Hackage. To check, I grepped my software directory which has all my
Haskell code, and got 122 matches of (:[]) over 1,768,231 loc (as given by
wc -l **/*.hs).

Matt Parsons


On Tue, Aug 13, 2019 at 4:56 PM Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> > The point is to create a monomorphic variant [...]
>
> But we already have at least two monomorphic variants to express this
> with Haskell's concise native syntax and vocabulary which has by
> design a preferential treatment of lists (it was considered even more
> important than type-sigs so that we got the `:` cons operator for
> lists and the `::` for type-sig annotations) -- so let's not try to
> fight Haskell's core idioms by hiding them behind some trivial
> additional redundant synonyms! I still fail to see the actual
> *technical* problem being solved by the original proposal asking to
> add yet another, wordy way to construct single-item-lists.
> _______________________________________________
> 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/20190813/b7b063f6/attachment.html>

From andrew.lelechenko at gmail.com  Tue Aug 13 23:32:26 2019
From: andrew.lelechenko at gmail.com (Andrew Lelechenko)
Date: Wed, 14 Aug 2019 00:32:26 +0100
Subject: Make sameNat proxy-polymorphic
Message-ID: <5B17BCF1-9064-490D-A785-D77EA74CF04A@gmail.com>

Hi all,

Currently base:GHC.TypeNats.sameNat is implemented as follows:

sameNat :: (KnownNat a, KnownNat b) => Proxy a -> Proxy b -> Maybe (a :~: b)
sameNat x y
  | natVal x == natVal y = Just (unsafeCoerce Refl)
  | otherwise = Nothing

There are applications, when more flexibility is desirable. I propose to change sameNat's type to 

sameNat :: (KnownNat a, KnownNat b) => proxy1 a -> proxy2 b -> Maybe (a :~: b)

It does not require any changes in the implementation, because natVal is already "proxy-polymorphic":

natVal :: forall n proxy. KnownNat n => proxy n -> Natural

Best regards,
Andrew

From taylor at fausak.me  Tue Aug 13 23:34:58 2019
From: taylor at fausak.me (Taylor Fausak)
Date: Tue, 13 Aug 2019 19:34:58 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CA+4qU94-QvzS0O9TyHPTQxw37NfN732bR3cJk_f1TN2zoMOR9Q@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <CA+4qU94-QvzS0O9TyHPTQxw37NfN732bR3cJk_f1TN2zoMOR9Q@mail.gmail.com>
Message-ID: <AC92663F-6671-45FC-B49A-EE98E1A985E4@fausak.me>

I want to echo everything Matt Parsons is saying. I also want to publicly thank him for participating in this discussion and for making solid arguments. Thanks, Matt!

By way of explanation, I was motivated to propose this addition because a member of my team wondered aloud if there was a function to do this. I told them that I didn’t know of one, but I typically used `pure` in point-free expressions and `[x]` when the value had already been named. We searched around and couldn’t find anything:

- https://www.stackage.org/lts-14.0/hoogle?q=a+-%3E+%5Ba%5D
- https://hoogle.haskell.org/?hoogle=a%20-%3E%20%5Ba%5D

We got to talking about other ways to express the same thing. (Everything we came up with has been seen in this thread already.) That got me wondering why there *wasn’t* a specific, monomorphic function for this. The omission seemed especially strange to my team member because they were familiar with Elm, which has this function. 

All that to say: This proposal is motivated by real confusion coming from a junior developer using Haskell at work. Consider how easy it is to discover and do something, rather than if it’s technically possible. 

> On Aug 13, 2019, at 7:20 PM, Matt <parsonsmatt at gmail.com> wrote:
> 
> `(\x -> [x])` has the same polymorphism problem in the context of `OverloadedLists` as `pure`.
> 
> `(:[])` is also unsatisfactory. To parse it properly, you need to:
> 
> - Know that `:` is only allowed as an operator to prefix data constructors,
> - Know that `[]` are not legal operator characters,
> - Infer that you're intended to insert a space between the `:` and `[]` to get `(: [])`
> - Recognize it as an operator section being used prefix as a normal function
> 
> I'm neither an expert nor a lifelong Haskeller, but I have been writing it in some professional capacity for four years now, and the operator section trips me up. I can't imagine less experienced folks find it easy or intuitive. You can't even search for it on hoogle: https://hoogle.haskell.org/?hoogle=(%3A%5B%5D)
> 
> Is `(:[])` a core idiom? I never see it in work code and I've never seen it in Hackage. To check, I grepped my software directory which has all my Haskell code, and got 122 matches of (:[]) over 1,768,231 loc (as given by wc -l **/*.hs).
> 
> Matt Parsons
> 
> 
>> On Tue, Aug 13, 2019 at 4:56 PM Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
>> > The point is to create a monomorphic variant [...]
>> 
>> But we already have at least two monomorphic variants to express this
>> with Haskell's concise native syntax and vocabulary which has by
>> design a preferential treatment of lists (it was considered even more
>> important than type-sigs so that we got the `:` cons operator for
>> lists and the `::` for type-sig annotations) -- so let's not try to
>> fight Haskell's core idioms by hiding them behind some trivial
>> additional redundant synonyms! I still fail to see the actual
>> *technical* problem being solved by the original proposal asking to
>> add yet another, wordy way to construct single-item-lists.
>> _______________________________________________
>> 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/20190813/71329a33/attachment.html>

From chessai1996 at gmail.com  Wed Aug 14 01:27:16 2019
From: chessai1996 at gmail.com (chessai .)
Date: Tue, 13 Aug 2019 21:27:16 -0400
Subject: Make sameNat proxy-polymorphic
In-Reply-To: <5B17BCF1-9064-490D-A785-D77EA74CF04A@gmail.com>
References: <5B17BCF1-9064-490D-A785-D77EA74CF04A@gmail.com>
Message-ID: <CAD34_k+u+fJmXwsnVvTfGd51Urmj2ASAESWnyhraC7cDiR75Mg@mail.gmail.com>

+1

On Tue, Aug 13, 2019, 7:32 PM Andrew Lelechenko <andrew.lelechenko at gmail.com>
wrote:

> Hi all,
>
> Currently base:GHC.TypeNats.sameNat is implemented as follows:
>
> sameNat :: (KnownNat a, KnownNat b) => Proxy a -> Proxy b -> Maybe (a :~:
> b)
> sameNat x y
>   | natVal x == natVal y = Just (unsafeCoerce Refl)
>   | otherwise = Nothing
>
> There are applications, when more flexibility is desirable. I propose to
> change sameNat's type to
>
> sameNat :: (KnownNat a, KnownNat b) => proxy1 a -> proxy2 b -> Maybe (a
> :~: b)
>
> It does not require any changes in the implementation, because natVal is
> already "proxy-polymorphic":
>
> natVal :: forall n proxy. KnownNat n => proxy n -> Natural
>
> Best regards,
> Andrew
> _______________________________________________
> 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/20190813/dfe0d8bb/attachment.html>

From emertens at gmail.com  Wed Aug 14 16:44:53 2019
From: emertens at gmail.com (Eric Mertens)
Date: Wed, 14 Aug 2019 09:44:53 -0700
Subject: Make sameNat proxy-polymorphic
In-Reply-To: <5B17BCF1-9064-490D-A785-D77EA74CF04A@gmail.com>
References: <5B17BCF1-9064-490D-A785-D77EA74CF04A@gmail.com>
Message-ID: <3C6646AE-67C6-4BAE-B105-6564347D8F44@gmail.com>

While we’re fixing that, let’s also fix sameSymbol.

> On Aug 13, 2019, at 4:32 PM, Andrew Lelechenko <andrew.lelechenko at gmail.com> wrote:
> 
> Hi all,
> 
> Currently base:GHC.TypeNats.sameNat is implemented as follows:
> 
> sameNat :: (KnownNat a, KnownNat b) => Proxy a -> Proxy b -> Maybe (a :~: b)
> sameNat x y
>  | natVal x == natVal y = Just (unsafeCoerce Refl)
>  | otherwise = Nothing
> 
> There are applications, when more flexibility is desirable. I propose to change sameNat's type to 
> 
> sameNat :: (KnownNat a, KnownNat b) => proxy1 a -> proxy2 b -> Maybe (a :~: b)
> 
> It does not require any changes in the implementation, because natVal is already "proxy-polymorphic":
> 
> natVal :: forall n proxy. KnownNat n => proxy n -> Natural
> 
> Best regards,
> Andrew
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


From hvriedel at gmail.com  Wed Aug 14 17:10:16 2019
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Wed, 14 Aug 2019 19:10:16 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CA+4qU94-QvzS0O9TyHPTQxw37NfN732bR3cJk_f1TN2zoMOR9Q@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <CA+4qU94-QvzS0O9TyHPTQxw37NfN732bR3cJk_f1TN2zoMOR9Q@mail.gmail.com>
Message-ID: <CAOFsAruu0xc_i0HBnY5kNBTw1k9UG5N+inzCT+aRzV84kPBa8w@mail.gmail.com>

> `(:[])` is also unsatisfactory

Which is a purely subjective assessment (and one I clearly disagree with)

> To parse it properly, you need to:
>
> - Know that `:` is only allowed as an operator to prefix data constructors,
> - Know that `[]` are not legal operator characters,
> - Infer that you're intended to insert a space between the `:` and `[]` to get `(: [])`
> - Recognize it as an operator section being used prefix as a normal function

Indeed, in order to parse a legit Haskell term, be it (0(,)), (:[0])
or (:".exe") or (:[]) you need to know the core Haskell98 syntax. I'm
aware that other languages such as Elm or Purescript favor different
ideals and design principles but that's not really a good argument to
make either; each language has its own idioms and point in the design
space.

I'm still waiting for a statement of the technical problem we're
trying to solve here which requires the introduction of a redundant
synonym for a concise facility we already have at our disposal by
virtue of the core Haskell98 syntax. Otherwise I'm afraid we're going
to be stuck in this discussion as everything on the topic has been
said and repeated in one way or another and so far we haven't reached
any consensus.

From parsonsmatt at gmail.com  Wed Aug 14 17:36:11 2019
From: parsonsmatt at gmail.com (Matt)
Date: Wed, 14 Aug 2019 11:36:11 -0600
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAOFsAruu0xc_i0HBnY5kNBTw1k9UG5N+inzCT+aRzV84kPBa8w@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <CA+4qU94-QvzS0O9TyHPTQxw37NfN732bR3cJk_f1TN2zoMOR9Q@mail.gmail.com>
 <CAOFsAruu0xc_i0HBnY5kNBTw1k9UG5N+inzCT+aRzV84kPBa8w@mail.gmail.com>
Message-ID: <CA+4qU94JDg=KnAxz0GsLiFN+NU7MN4rHbgH-HA_Y9pa6V=kinQ@mail.gmail.com>

There have been 19 votes cast so far. We have twelve +1 votes. Of the -1
votes, three are because "`pure` is fine" and four are because "`(:[])` is
fine." I summarized the issue with `pure` in my previous email, and there
hasn't been any response or comment on the issues raised.

To summarize/quote the issues with `(:[])`:

> You can't even search for it on hoogle:
https://hoogle.haskell.org/?hoogle=(%3A%5B%5D)
> Another advantage to having an explicit singleton function is
discoverablity.

The discoverability of `(:[])` is bad.

> Is `(:[])` a core idiom? I never see it in work code and I've never seen
it in Hackage. To check, I grepped my software directory which has all my
Haskell code, and got 122 matches of (:[]) over 1,768,231 loc (as given by
wc -l **/*.hs).

`(:[])` is not a common idiom (in the code sample I have; your mileage may
vary).

> All alternatives to construct a list "anonymously" are confusing and take
time to parse.
> The `(:[])` operator takes me a decent amount longer to parse and
recognize, and I have seen intermediate-level Haskellers trip up over
unspaced operators like this in several contexts.

The operator section is confusing and difficult to parse in this context.

Those are the three main problems that people have with `(:[])`, as far as
I can tell.

Matt Parsons


On Wed, Aug 14, 2019 at 11:10 AM Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> > `(:[])` is also unsatisfactory
>
> Which is a purely subjective assessment (and one I clearly disagree with)
>
> > To parse it properly, you need to:
> >
> > - Know that `:` is only allowed as an operator to prefix data
> constructors,
> > - Know that `[]` are not legal operator characters,
> > - Infer that you're intended to insert a space between the `:` and `[]`
> to get `(: [])`
> > - Recognize it as an operator section being used prefix as a normal
> function
>
> Indeed, in order to parse a legit Haskell term, be it (0(,)), (:[0])
> or (:".exe") or (:[]) you need to know the core Haskell98 syntax. I'm
> aware that other languages such as Elm or Purescript favor different
> ideals and design principles but that's not really a good argument to
> make either; each language has its own idioms and point in the design
> space.
>
> I'm still waiting for a statement of the technical problem we're
> trying to solve here which requires the introduction of a redundant
> synonym for a concise facility we already have at our disposal by
> virtue of the core Haskell98 syntax. Otherwise I'm afraid we're going
> to be stuck in this discussion as everything on the topic has been
> said and repeated in one way or another and so far we haven't reached
> any consensus.
> _______________________________________________
> 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/20190814/2b4b63e8/attachment.html>

From ollie at ocharles.org.uk  Wed Aug 14 19:34:43 2019
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Wed, 14 Aug 2019 20:34:43 +0100
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CA+4qU94JDg=KnAxz0GsLiFN+NU7MN4rHbgH-HA_Y9pa6V=kinQ@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <CA+4qU94-QvzS0O9TyHPTQxw37NfN732bR3cJk_f1TN2zoMOR9Q@mail.gmail.com>
 <CAOFsAruu0xc_i0HBnY5kNBTw1k9UG5N+inzCT+aRzV84kPBa8w@mail.gmail.com>
 <CA+4qU94JDg=KnAxz0GsLiFN+NU7MN4rHbgH-HA_Y9pa6V=kinQ@mail.gmail.com>
Message-ID: <CAGRp5Rn3zTce_dGhKQj3YRNnLS3Fwfy_LVTT-OSQxkaLt7RJFA@mail.gmail.com>

I'd also be interested in a kind of "reverse" argument - *if* we had this
added, what are the costs? There are arguments of "no, pure/robot ninja is
enough" - fine, we're not taking those away so you aren't required to use
singleton  But what is the *downside* of having singleton?

It's basically write once, so I don't see an increase of maintenance burden
in the prelude.

Of course, if people start to use it and you don't, there is a bit of
conflict when it comes to reading others code. It's a slightly longer name,
but the name itself is pretty clear. Even if you don't have it fully
qualified, it's clear that it constructs a single element of something -
the only syntax with potentially more information is the robot ninja
operator (in the absence of overloaded lists), which makes it unambiguously
about lists. So I think for people comfortable with pure/robot ninja, they
would also be able to understand code using singleton. OTOH, the opposite
doesn't seem to follow.

So, to the -1s, did I miss anything else?

On Wed, 14 Aug 2019, 6:37 pm Matt, <parsonsmatt at gmail.com> wrote:

> There have been 19 votes cast so far. We have twelve +1 votes. Of the -1
> votes, three are because "`pure` is fine" and four are because "`(:[])` is
> fine." I summarized the issue with `pure` in my previous email, and there
> hasn't been any response or comment on the issues raised.
>
> To summarize/quote the issues with `(:[])`:
>
> > You can't even search for it on hoogle:
> https://hoogle.haskell.org/?hoogle=(%3A%5B%5D)
> > Another advantage to having an explicit singleton function is
> discoverablity.
>
> The discoverability of `(:[])` is bad.
>
> > Is `(:[])` a core idiom? I never see it in work code and I've never seen
> it in Hackage. To check, I grepped my software directory which has all my
> Haskell code, and got 122 matches of (:[]) over 1,768,231 loc (as given by
> wc -l **/*.hs).
>
> `(:[])` is not a common idiom (in the code sample I have; your mileage may
> vary).
>
> > All alternatives to construct a list "anonymously" are confusing and
> take time to parse.
> > The `(:[])` operator takes me a decent amount longer to parse and
> recognize, and I have seen intermediate-level Haskellers trip up over
> unspaced operators like this in several contexts.
>
> The operator section is confusing and difficult to parse in this context.
>
> Those are the three main problems that people have with `(:[])`, as far as
> I can tell.
>
> Matt Parsons
>
>
> On Wed, Aug 14, 2019 at 11:10 AM Herbert Valerio Riedel <
> hvriedel at gmail.com> wrote:
>
>> > `(:[])` is also unsatisfactory
>>
>> Which is a purely subjective assessment (and one I clearly disagree with)
>>
>> > To parse it properly, you need to:
>> >
>> > - Know that `:` is only allowed as an operator to prefix data
>> constructors,
>> > - Know that `[]` are not legal operator characters,
>> > - Infer that you're intended to insert a space between the `:` and `[]`
>> to get `(: [])`
>> > - Recognize it as an operator section being used prefix as a normal
>> function
>>
>> Indeed, in order to parse a legit Haskell term, be it (0(,)), (:[0])
>> or (:".exe") or (:[]) you need to know the core Haskell98 syntax. I'm
>> aware that other languages such as Elm or Purescript favor different
>> ideals and design principles but that's not really a good argument to
>> make either; each language has its own idioms and point in the design
>> space.
>>
>> I'm still waiting for a statement of the technical problem we're
>> trying to solve here which requires the introduction of a redundant
>> synonym for a concise facility we already have at our disposal by
>> virtue of the core Haskell98 syntax. Otherwise I'm afraid we're going
>> to be stuck in this discussion as everything on the topic has been
>> said and repeated in one way or another and so far we haven't reached
>> any consensus.
>> _______________________________________________
>> 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/20190814/1fedb517/attachment.html>

From svenpanne at gmail.com  Wed Aug 14 19:36:37 2019
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 14 Aug 2019 21:36:37 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CA+4qU94JDg=KnAxz0GsLiFN+NU7MN4rHbgH-HA_Y9pa6V=kinQ@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <CA+4qU94-QvzS0O9TyHPTQxw37NfN732bR3cJk_f1TN2zoMOR9Q@mail.gmail.com>
 <CAOFsAruu0xc_i0HBnY5kNBTw1k9UG5N+inzCT+aRzV84kPBa8w@mail.gmail.com>
 <CA+4qU94JDg=KnAxz0GsLiFN+NU7MN4rHbgH-HA_Y9pa6V=kinQ@mail.gmail.com>
Message-ID: <CANBN=mv=05fX_3CA+_fNnnNkdUHgUd7VXmVJYrpvV-u4je2NtA@mail.gmail.com>

Am Mi., 14. Aug. 2019 um 19:37 Uhr schrieb Matt <parsonsmatt at gmail.com>:

> There have been 19 votes cast so far. We have twelve +1 votes.
>

-1 from me, so we have 7 -1s now. >:-) BTW: Simply counting a tiny amount
of votes in a niche mailing list is not the best way to design APIs IMHO.


> Of the -1 votes, three are because "`pure` is fine" and four are because
> "`(:[])` is fine." I summarized the issue with `pure` in my previous email,
> and there hasn't been any response or comment on the issues raised.
>

I still fail to see the issues with "pure". Let's be honest: If somebody
has problems with polymorphic functions or operator sections, he will have
a hard time with Haskell in general. These are fundamental things in your
toolbox, and instead of coming up with tons of names which nobody can
remember (Fairbairn threshold, anyone?) for trivial things, time is better
spent educating people. Compared to the stuff you currently see in most
modern libraries (GADTs, lenses, type-level computations, ...)
understanding "pure" or "(: [])" will be your least problem.


> To summarize/quote the issues with `(:[])`:
>
> > You can't even search for it on hoogle:
> https://hoogle.haskell.org/?hoogle=(%3A%5B%5D)
> > Another advantage to having an explicit singleton function is
> discoverablity.
>
> The discoverability of `(:[])` is bad.
>

Why should I need to discover it when I can write it with 6 keystrokes (or
even 4)? Or as "\x -> [x]", which is basically a matter of taste?


> > Is `(:[])` a core idiom? I never see it in work code and I've never seen
> it in Hackage. To check, I grepped my software directory which has all my
> Haskell code, and got 122 matches of (:[]) over 1,768,231 loc (as given by
> wc -l **/*.hs).
>
> `(:[])` is not a common idiom (in the code sample I have; your mileage may
> vary).
>

It is quite obvious to me why you don't find it much in code. You have lots
of other ways to express the same thing:

   * You'll probably just use "[x]" if the argument already has a name.

   * If the argument doesn't have a name, you can give it one via "\x ->
[x]" (which I consider "explicit", not "noisy") or perhaps via eta
abstraction.

   * The code is intended to be polymorphic => "pure" is used.

   * Even if it's intended to be used monomorphic, there are often type
signatures around to make "pure" monomorphic enough.

This doesn't leave many sensible places. Perhaps as an argument for a
function, with very few type signatures around? Not a very convincing use
case IMHO.

In a nutshell: Just like Herbert, I can't see the problem we're trying to
solve. I would go even further: I would like to see a much more general
Prelude/base library, not a more monomorphic one. Pages like
https://haskell.fpcomplete.com/tutorial/synonyms cause quite a few "WTF?"
moments caused by the (nowadays) useless synonyms...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190814/a21df6dc/attachment.html>

From svenpanne at gmail.com  Wed Aug 14 19:51:15 2019
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 14 Aug 2019 21:51:15 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAGRp5Rn3zTce_dGhKQj3YRNnLS3Fwfy_LVTT-OSQxkaLt7RJFA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <CA+4qU94-QvzS0O9TyHPTQxw37NfN732bR3cJk_f1TN2zoMOR9Q@mail.gmail.com>
 <CAOFsAruu0xc_i0HBnY5kNBTw1k9UG5N+inzCT+aRzV84kPBa8w@mail.gmail.com>
 <CA+4qU94JDg=KnAxz0GsLiFN+NU7MN4rHbgH-HA_Y9pa6V=kinQ@mail.gmail.com>
 <CAGRp5Rn3zTce_dGhKQj3YRNnLS3Fwfy_LVTT-OSQxkaLt7RJFA@mail.gmail.com>
Message-ID: <CANBN=muuP=agYGw1a-bHqN7r8eqZRp5X8odEwm1UmqK277TW1A@mail.gmail.com>

Am Mi., 14. Aug. 2019 um 21:35 Uhr schrieb Oliver Charles <
ollie at ocharles.org.uk>:

> I'd also be interested in a kind of "reverse" argument - *if* we had this
> added, what are the costs? There are arguments of "no, pure/robot ninja is
> enough" - fine, we're not taking those away so you aren't required to use
> singleton  But what is the *downside* of having singleton? [...]
>

A similar argument comes up with basically every extension, and it is a
very weak one. Code is mainly *read*, not written, so the less you need to
know to read and understand code, the better it is. Lots of different ways
to do the same thing makes programs harder to understand, and you
ultimately end up with Perl. :-}  And if we take this argument seriously,
we should probably add "doubleton" (synonym for "replicate 2"), "tripleton"
(synonym for "replicate 3"), etc., too.  Hey, you don't have to use it
after all, we're not taking away "replicate"...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190814/9559201a/attachment.html>

From fa-ml at ariis.it  Wed Aug 14 19:59:06 2019
From: fa-ml at ariis.it (Francesco Ariis)
Date: Wed, 14 Aug 2019 21:59:06 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CANBN=mv=05fX_3CA+_fNnnNkdUHgUd7VXmVJYrpvV-u4je2NtA@mail.gmail.com>
 <CAGRp5Rn3zTce_dGhKQj3YRNnLS3Fwfy_LVTT-OSQxkaLt7RJFA@mail.gmail.com>
Message-ID: <20190814195906.a7xzt62hizek7koh@x60s.casa>

On Wed, Aug 14, 2019 at 08:34:43PM +0100, Oliver Charles wrote:
> I'd also be interested in a kind of "reverse" argument - *if* we had this
> added, what are the costs? There are arguments of "no, pure/robot ninja is
> enough" - fine, we're not taking those away so you aren't required to use
> singleton  But what is the *downside* of having singleton?

I slightly prefer `singleton` myself; adding it to `Data.List`
*will* break some code though (Ambiguous occurrence ‘singleton’
etc etc. when you import, say, Data.Map unqualified).

On Wed, Aug 14, 2019 at 09:36:37PM +0200, Sven Panne wrote:
> Am Mi., 14. Aug. 2019 um 19:37 Uhr schrieb Matt <parsonsmatt at gmail.com>:
>
> > There have been 19 votes cast so far. We have twelve +1 votes.
> >
>
> -1 from me, so we have 7 -1s now. >:-) BTW: Simply counting a tiny amount
> of votes in a niche mailing list is not the best way to design APIs IMHO.

Amen, let CLC reach consensus!


From andreas.abel at ifi.lmu.de  Thu Aug 15 17:23:27 2019
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Thu, 15 Aug 2019 19:23:27 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CANBN=muuP=agYGw1a-bHqN7r8eqZRp5X8odEwm1UmqK277TW1A@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <CA+4qU94-QvzS0O9TyHPTQxw37NfN732bR3cJk_f1TN2zoMOR9Q@mail.gmail.com>
 <CAOFsAruu0xc_i0HBnY5kNBTw1k9UG5N+inzCT+aRzV84kPBa8w@mail.gmail.com>
 <CA+4qU94JDg=KnAxz0GsLiFN+NU7MN4rHbgH-HA_Y9pa6V=kinQ@mail.gmail.com>
 <CAGRp5Rn3zTce_dGhKQj3YRNnLS3Fwfy_LVTT-OSQxkaLt7RJFA@mail.gmail.com>
 <CANBN=muuP=agYGw1a-bHqN7r8eqZRp5X8odEwm1UmqK277TW1A@mail.gmail.com>
Message-ID: <9e566065-a2dd-d305-e81a-8122dba6fa67@ifi.lmu.de>

Sven Panne wrote:

 > Code is mainly *read*, not written, so the less you need
 > to know to read and understand code, the better it is.

Yes, and this is an argument *for* singleton, not against:

1. singleton is already known to the Haskell reader from the other 
collection types.

2. singleton is unambiguously invoking the image of creating a singleton 
collection.

In contrast, "pure" invokes the image of creating a effect-free monadic 
computation.  (:[]) invokes the image of a (mechanical) gorilla smiling 
at you. ;-)  All these associations distract from reading the code.  In 
both cases, a mental translation step is needed:

a) In the case of "pure", the conscious intervention that here we are 
not concerned with non-determinism (the list monad), but just creating a 
singleton collection.

b) In the case of "(:[])", the conscious intervention consists of
    - recognizing the decomposition (: [])
    - recognizing the operator section
    - understanding it as "cons something to the empty list"
    - understanding this as creating a singleton collection.

Both interventions hamper the flow of reading.

Of course, the procedure b) becomes automatic with use.  However, it is 
still a significant barrier to the newcomer.

Cheers,
Andreas

P.S.: if the gorilla (:[]) is vanishing from the Agda code base, I am 
mostly to be blamed for this.

On 2019-08-14 21:51, Sven Panne wrote:
> Am Mi., 14. Aug. 2019 um 21:35 Uhr schrieb Oliver Charles 
> <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
> 
>     I'd also be interested in a kind of "reverse" argument - *if* we had
>     this added, what are the costs? There are arguments of "no,
>     pure/robot ninja is enough" - fine, we're not taking those away so
>     you aren't required to use singleton  But what is the *downside* of
>     having singleton? [...]
> 
> 
> A similar argument comes up with basically every extension, and it is a 
> very weak one. Code is mainly *read*, not written, so the less you need 
> to know to read and understand code, the better it is. Lots of different 
> ways to do the same thing makes programs harder to understand, and you 
> ultimately end up with Perl. :-}  And if we take this argument 
> seriously, we should probably add "doubleton" (synonym for "replicate 
> 2"), "tripleton" (synonym for "replicate 3"), etc., too.  Hey, you don't 
> have to use it after all, we're not taking away "replicate"...
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> 

From scott.c.marks at gmail.com  Thu Aug 15 18:03:09 2019
From: scott.c.marks at gmail.com (Scott Marks)
Date: Thu, 15 Aug 2019 14:03:09 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <9e566065-a2dd-d305-e81a-8122dba6fa67@ifi.lmu.de>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <CA+4qU94-QvzS0O9TyHPTQxw37NfN732bR3cJk_f1TN2zoMOR9Q@mail.gmail.com>
 <CAOFsAruu0xc_i0HBnY5kNBTw1k9UG5N+inzCT+aRzV84kPBa8w@mail.gmail.com>
 <CA+4qU94JDg=KnAxz0GsLiFN+NU7MN4rHbgH-HA_Y9pa6V=kinQ@mail.gmail.com>
 <CAGRp5Rn3zTce_dGhKQj3YRNnLS3Fwfy_LVTT-OSQxkaLt7RJFA@mail.gmail.com>
 <CANBN=muuP=agYGw1a-bHqN7r8eqZRp5X8odEwm1UmqK277TW1A@mail.gmail.com>
 <9e566065-a2dd-d305-e81a-8122dba6fa67@ifi.lmu.de>
Message-ID: <CAJJU6fV3T21tnxx+GFs9OXMJLseP1dD4LD8dBx1PEZ6zjObRLA@mail.gmail.com>

I confess I am a minimalist. Been coding Haskell for a year after a break
(my 1982 dissertation was “Optimization of Functional Programs” so my
interest goes back a ways).  Were I the God of Haskell I would go down the
above-mentioned synonym list and deprecate all the less-general “return”
things.

I confess also that the semantics of “pure” seems in some cases ((,), etc)
to have been chosen for pragmatic reason; inevitably one must choose an
embedding when there is a choice, and “I got there first” can be justified
if it produces lots of elegant simplicity. To my taste it’s too bad that
Collection means “ordered collection” but I imagine that there are more
applications in which deterministic iteration is useful.

All that being said, I vote for singleton as a readable method name for
Collection instances.
To my way of thinking this implies picking a Collection class and moving it
closer to the Root of all Haskell.

On Thu, Aug 15, 2019 at 13:23 Andreas Abel <andreas.abel at ifi.lmu.de> wrote:

> Sven Panne wrote:
>
>  > Code is mainly *read*, not written, so the less you need
>  > to know to read and understand code, the better it is.
>
> Yes, and this is an argument *for* singleton, not against:
>
> 1. singleton is already known to the Haskell reader from the other
> collection types.
>
> 2. singleton is unambiguously invoking the image of creating a singleton
> collection.
>
> In contrast, "pure" invokes the image of creating a effect-free monadic
> computation.  (:[]) invokes the image of a (mechanical) gorilla smiling
> at you. ;-)  All these associations distract from reading the code.  In
> both cases, a mental translation step is needed:
>
> a) In the case of "pure", the conscious intervention that here we are
> not concerned with non-determinism (the list monad), but just creating a
> singleton collection.
>
> b) In the case of "(:[])", the conscious intervention consists of
>     - recognizing the decomposition (: [])
>     - recognizing the operator section
>     - understanding it as "cons something to the empty list"
>     - understanding this as creating a singleton collection.
>
> Both interventions hamper the flow of reading.
>
> Of course, the procedure b) becomes automatic with use.  However, it is
> still a significant barrier to the newcomer.
>
> Cheers,
> Andreas
>
> P.S.: if the gorilla (:[]) is vanishing from the Agda code base, I am
> mostly to be blamed for this.
>
> On 2019-08-14 21:51, Sven Panne wrote:
> > Am Mi., 14. Aug. 2019 um 21:35 Uhr schrieb Oliver Charles
> > <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
> >
> >     I'd also be interested in a kind of "reverse" argument - *if* we had
> >     this added, what are the costs? There are arguments of "no,
> >     pure/robot ninja is enough" - fine, we're not taking those away so
> >     you aren't required to use singleton  But what is the *downside* of
> >     having singleton? [...]
> >
> >
> > A similar argument comes up with basically every extension, and it is a
> > very weak one. Code is mainly *read*, not written, so the less you need
> > to know to read and understand code, the better it is. Lots of different
> > ways to do the same thing makes programs harder to understand, and you
> > ultimately end up with Perl. :-}  And if we take this argument
> > seriously, we should probably add "doubleton" (synonym for "replicate
> > 2"), "tripleton" (synonym for "replicate 3"), etc., too.  Hey, you don't
> > have to use it after all, we're not taking away "replicate"...
> >
> > _______________________________________________
> > 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/20190815/b85f021c/attachment.html>

From carter.schonwald at gmail.com  Fri Aug 16 01:17:10 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 15 Aug 2019 21:17:10 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <C3BDE1D7-AB22-4A68-AA0A-3B5CD82173FC@gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
 <CAK7nUjjOOa_E_UbjV1fDirYKrizxsZf7CXaGmWMhMNHR62-qpg@mail.gmail.com>
 <CAH0njdsmq_iqAG+y2tz3TovOSAQkUPh-e_HndFQ8oJDmSAHQ=A@mail.gmail.com>
 <C3BDE1D7-AB22-4A68-AA0A-3B5CD82173FC@gmail.com>
Message-ID: <CAHYVw0zJPBTzu-os=STba=6tEXUoFfzhPaNTQwNL6uXKOZyRng@mail.gmail.com>

Hard -1, , i'm not seeing a useful high impact payoff

plus its more verbose and adhoc than pure and more confusing than (:[])

I actually initially thought this thread was about Type Singletons and or
Proxy style apis using List as the term level form, it actually took me a
few minutes of reading everyone's replies to disambiguate

i'm open to changing my mind later if i can convince myself, but -1 for now

On Mon, Aug 12, 2019 at 3:53 PM Andrew Lelechenko <
andrew.lelechenko at gmail.com> wrote:

> - `pure`: Polymorphic, works for any `Functor`.
>
>
> It is OK to have polymorphic folds and length, so what is wrong with pure?
>
> Adding singleton to Data.List is a breaking change, when
> Data.Map.singleton was exported unqualified.
> And there is no singleton in Data.List.NonEmpty as well.
>
> -1 from me.
>
> Best regards,
> Andrew
>
> On 12 Aug 2019, at 19:36, Brent Yorgey <byorgey at gmail.com> wrote:
>
> At the risk of completely derailing the conversation, I have always called
> this the "robot monkey operator".  I fail to see what is so ninja-like
> about it.
>
> Anyway, I think I am +1 on adding Data.List.singleton.
>
> -Brent
>
> On Mon, Aug 12, 2019, 12:35 PM Zemyla <zemyla at gmail.com> wrote:
>
>> I also like the ninja-robot operator, because it's visually
>> interesting and easy to search for.
>>
>> Also, if you're importing several libraries which already use
>> "singleton", then you have to use "List.singleton" every time, which
>> is far uglier to me.
>>
>> On Mon, Aug 12, 2019 at 12:03 PM Herbert Valerio Riedel
>> <hvriedel at gmail.com> wrote:
>> >
>> > > - `(:[])`: Subjectively ugly.
>> >
>> > I consider "subjectively ugly" to be a non-technical and thus really
>> > weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])
>> > which also happens to be shorter than the proposed alias for it. I for
>> > one don't see a significant benefit for adding a redundant synonym to
>> > `Data.List` and are thus -1 on this.
>> >
>> > > singleton :: a -> [a]
>> > > singleton x = [x]
>> > _______________________________________________
>> > 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
>
>
> _______________________________________________
> 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/20190815/73dc5aa2/attachment.html>

From carter.schonwald at gmail.com  Fri Aug 16 01:20:02 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 15 Aug 2019 21:20:02 -0400
Subject: Make sameNat proxy-polymorphic
In-Reply-To: <3C6646AE-67C6-4BAE-B105-6564347D8F44@gmail.com>
References: <5B17BCF1-9064-490D-A785-D77EA74CF04A@gmail.com>
 <3C6646AE-67C6-4BAE-B105-6564347D8F44@gmail.com>
Message-ID: <CAHYVw0yy9R93Xd=4C6manZoApR8c=bo4WUHjHudta5mhasLuaQ@mail.gmail.com>

+1 on all of the above, I generally find my proxy code is nicest when i'm
polymoprophic over the prox :)

On Wed, Aug 14, 2019 at 12:45 PM Eric Mertens <emertens at gmail.com> wrote:

> While we’re fixing that, let’s also fix sameSymbol.
>
> > On Aug 13, 2019, at 4:32 PM, Andrew Lelechenko <
> andrew.lelechenko at gmail.com> wrote:
> >
> > Hi all,
> >
> > Currently base:GHC.TypeNats.sameNat is implemented as follows:
> >
> > sameNat :: (KnownNat a, KnownNat b) => Proxy a -> Proxy b -> Maybe (a
> :~: b)
> > sameNat x y
> >  | natVal x == natVal y = Just (unsafeCoerce Refl)
> >  | otherwise = Nothing
> >
> > There are applications, when more flexibility is desirable. I propose to
> change sameNat's type to
> >
> > sameNat :: (KnownNat a, KnownNat b) => proxy1 a -> proxy2 b -> Maybe (a
> :~: b)
> >
> > It does not require any changes in the implementation, because natVal is
> already "proxy-polymorphic":
> >
> > natVal :: forall n proxy. KnownNat n => proxy n -> Natural
> >
> > Best regards,
> > Andrew
> > _______________________________________________
> > 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/20190815/53623c53/attachment.html>

From carter.schonwald at gmail.com  Fri Aug 16 01:36:10 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 15 Aug 2019 21:36:10 -0400
Subject: Add instance MonadFail (f :*: g)
In-Reply-To: <CAJumaK_gQf0ALX3bmvZAFJvy_Qxg36A5P0j1AtVMFWGm2JpRLg@mail.gmail.com>
References: <CAKM3oZVPOx9fhFuTv+75WNiuAGYOF910y5-HknxOh47avXaOcA@mail.gmail.com>
 <CAJumaK_gQf0ALX3bmvZAFJvy_Qxg36A5P0j1AtVMFWGm2JpRLg@mail.gmail.com>
Message-ID: <CAHYVw0y0CRgfon8L5q7D6_VW958KdbF0YkvUwbUsYfFcq+LpNw@mail.gmail.com>

sounds good to me

On Mon, Aug 12, 2019 at 4:19 AM Edward Kmett <ekmett at gmail.com> wrote:

> Works for me. +1
>
> On Sun, Aug 11, 2019 at 12:38 PM Dannyu NDos <ndospark320 at gmail.com>
> wrote:
>
>> instance (MonadFail f, MonadFail g) => MonadFail (f :*: g) where
>>     fail s = fail s :*: fail s
>> _______________________________________________
>> 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/20190815/bc36fadd/attachment.html>

From b at chreekat.net  Fri Aug 16 04:47:08 2019
From: b at chreekat.net (Bryan Richter)
Date: Fri, 16 Aug 2019 07:47:08 +0300
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAHYVw0zJPBTzu-os=STba=6tEXUoFfzhPaNTQwNL6uXKOZyRng@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
 <CAK7nUjjOOa_E_UbjV1fDirYKrizxsZf7CXaGmWMhMNHR62-qpg@mail.gmail.com>
 <CAH0njdsmq_iqAG+y2tz3TovOSAQkUPh-e_HndFQ8oJDmSAHQ=A@mail.gmail.com>
 <C3BDE1D7-AB22-4A68-AA0A-3B5CD82173FC@gmail.com>
 <CAHYVw0zJPBTzu-os=STba=6tEXUoFfzhPaNTQwNL6uXKOZyRng@mail.gmail.com>
Message-ID: <354151cd-a0c1-3b4a-42de-19cea8a65f13@chreekat.net>

On 8/16/19 4:17 AM, Carter Schonwald wrote:

> Hard -1, , i'm not seeing a useful high impact payoff
>
> plus its more verbose and adhoc than pure and more confusing than
> (:[])
>
> I actually initially thought this thread was about Type Singletons
> and or Proxy style apis using List as the term level form, it
> actually took me a few minutes of reading everyone's replies to
> disambiguate

If a value-level 'singleton' is confusing to anybody, I have really[1]
quite[2] terrible[3], in[4] fact[5] downright[6] awful[7] news[8]. :)

+1 to Data.List.singleton and Data.List.NonEmpty.singleton from me in
the peanut gallery. I agree with the sentiment that 'pure @ []' means
"side effect-free nondeterministic value", which is quite different
than meaning "a list with one element", and is therefore possibly more
ad hoc than using the well-established 'singleton'.

But I also joyfully assent to the decision of the CLC! Besides the
possibility for breakage (can we use head.hackage to get hard data
here?), I have not seen a single "technical", data-based argument from
either side. Even asking the proponents to provide technical
arguments, after all, is a subjective criterion.

With respectful acknowledgement of all positions taken,

-Bryan

[1]: https://hackage.haskell.org/package/bytestring/docs/Data-ByteString.html#v:singleton
[2]: https://hackage.haskell.org/package/containers/docs/Data-IntMap-Internal.html#v:singleton
[3]: https://hackage.haskell.org/package/text/docs/Data-Text.html#v:singleton
[4]: https://hackage.haskell.org/package/vector/docs/Data-Vector.html#v:singleton
[5]: https://hackage.haskell.org/package/unordered-containers/docs/Data-HashSet.html#v:singleton
[6]: https://hackage.haskell.org/package/lens/docs/Control-Lens-Internal-Deque.html#v:singleton
[7]: https://hackage.haskell.org/package/Cabal/docs/Distribution-Compat-DList.html#v:singleton
[8]: https://hackage.haskell.org/package/memory/docs/Data-ByteArray.html#v:singleton

p.s. I've intentionally chosen eight different packages, some of which
include a number of different 'singleton's!


From kindaro at gmail.com  Fri Aug 16 14:21:11 2019
From: kindaro at gmail.com (Ignat Insarov)
Date: Fri, 16 Aug 2019 17:21:11 +0300
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
Message-ID: <CAB-2Q0_-c5-6Su_xFXFEpx5sX2K2nrn-s9t9kSetZPBXw1pu-A@mail.gmail.com>

I'd like to derail this conversation into remembering the "C, Unix hoax" joke.
https://www.gnu.org/fun/jokes/unix-hoax.html

> We stopped when we got a clean compile on the following syntax:
>
>     for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

We humans find it easier to think in words, which are singleton blobs
of sense requiring no parsing, no compilation, but immediately
obvious. The "monkey face" here is not one, not two, but four distinct
blobs. This is in fact a technical argument against it, though
referring to the technic of human cognition rather than machine's.

In this perspective, is it not clear that we should strive away from
symbol soup idioms? Let us write programs for people to read.

On Mon, 12 Aug 2019 at 20:03, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
>
> > - `(:[])`: Subjectively ugly.
>
> I consider "subjectively ugly" to be a non-technical and thus really
> weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])
> which also happens to be shorter than the proposed alias for it. I for
> one don't see a significant benefit for adding a redundant synonym to
> `Data.List` and are thus -1 on this.
>
> > singleton :: a -> [a]
> > singleton x = [x]
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From duke.j.david at gmail.com  Fri Aug 16 17:17:14 2019
From: duke.j.david at gmail.com (David Duke)
Date: Fri, 16 Aug 2019 18:17:14 +0100
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAB-2Q0_-c5-6Su_xFXFEpx5sX2K2nrn-s9t9kSetZPBXw1pu-A@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAOFsArtpar1pJS-kd-bduLJmrRDwK32=K-zgnG58NCEL_4=kwA@mail.gmail.com>
 <CAB-2Q0_-c5-6Su_xFXFEpx5sX2K2nrn-s9t9kSetZPBXw1pu-A@mail.gmail.com>
Message-ID: <CAN7OfXQjx83xD0iS-J0pe-MvuJZDkK=6gqDN7xA1JNJkm_F1yg@mail.gmail.com>

Whilst taking the point, could I just  pit out that, its not just about the
form of the final program. One of the
strengths and appeals of FP id the opportunity for program transformation
via a useful
repertoire of algebraic law, cf the work on Squiggol, and the numerous
pearls by folk including Richard Bird et.al..
This work befits from having concisely-expressed rules that open the road
to manipulation - long-winded
identifiers suitable for large libraries are not necessarily ideal here.
Going back to the original proposal, I'm not bothered, I would probably
just ignore a singleton library
in favour of  :[]. I'm -1 on philosophical grounds.
I'm used to teaching FP to undergrads and half the battle is encouraging
people to think functionally, to
make use of the underlying mathematics and computational model rather than
transliterate
Python or <insert your favourite 'bete noir'> into Haskell. That means
thinking of building programs from
functional fragments combined by suitable glue, and appreciating that data
constructors can be used
as functions Yes takes beginner's time to recognise some of the patterns,
but when the light dawns,
the transformation is rewarding. I've lost count of the number of jaws I've
had to pick off the floor :)

So I don't want to make a mountain out of a molehill. If it will really
improve people's programming
lives then fine, But I' not convinced, and but in fretting over final code
can we please not   lose
sight of the larger picture and battle..


regards
David Duke.

On Fri, Aug 16, 2019 at 3:21 PM Ignat Insarov <kindaro at gmail.com> wrote:

> I'd like to derail this conversation into remembering the "C, Unix hoax"
> joke.
> https://www.gnu.org/fun/jokes/unix-hoax.html
>
> > We stopped when we got a clean compile on the following syntax:
> >
> >     for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("|
> "+(*u/4)%2);
>
> We humans find it easier to think in words, which are singleton blobs
> of sense requiring no parsing, no compilation, but immediately
> obvious. The "monkey face" here is not one, not two, but four distinct
> blobs. This is in fact a technical argument against it, though
> referring to the technic of human cognition rather than machine's.
>
> In this perspective, is it not clear that we should strive away from
> symbol soup idioms? Let us write programs for people to read.
>
> On Mon, 12 Aug 2019 at 20:03, Herbert Valerio Riedel <hvriedel at gmail.com>
> wrote:
> >
> > > - `(:[])`: Subjectively ugly.
> >
> > I consider "subjectively ugly" to be a non-technical and thus really
> > weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])
> > which also happens to be shorter than the proposed alias for it. I for
> > one don't see a significant benefit for adding a redundant synonym to
> > `Data.List` and are thus -1 on this.
> >
> > > singleton :: a -> [a]
> > > singleton x = [x]
> > _______________________________________________
> > 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
>


-- 
David Duke
Professor of Computer Science
School of Computing University of Leeds UK
E:duke.j.david at gmail.com
W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190816/1cdc7583/attachment.html>

From david.feuer at gmail.com  Sat Aug 17 06:16:36 2019
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 17 Aug 2019 13:16:36 +0700
Subject: Proposal: add indexed map and traverse to Data.List
Message-ID: <CAMgWh9uuxAm87z_eJhV7RbkHwMQkoTnGQLFagxeVtzxfvc21LQ@mail.gmail.com>

mapWithIndex :: (Int -> a -> b) -> [a] -> [b]
mapWithIndex f = zipWith f [0..]

traverseWithIndex :: Applicative f => (Int -> a -> f b) -> [a] -> f [b]
traverseWithIndex f = sequenceA . mapWithIndex

The real implementation of mapWithIndex (and therefore of
traverseWithIndex) can be a "good consumer" for list fusion. mapWithIndex
can be a "good producer" as well (which the naive implementation already
accomplishes).

Similar functions (with these or similar names) are already common in
packages like vector, containers, unordered-containers, and primitive.

A more general function would merge zipping with unfolding:

zipWithUnfoldr :: (a -> b -> c) -> (s -> Maybe (b, s)) -> [a] -> s -> [c]
zipWithUnfoldr f g as s = zipWith f as (unfoldr g s)

But this doesn't seem like the friendliest or most obvious user interface,
so I am not proposing to add it to base.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190817/bdb6dd37/attachment.html>

From kovanikov at gmail.com  Sat Aug 17 08:46:47 2019
From: kovanikov at gmail.com (Dmitriy Kovanikov)
Date: Sat, 17 Aug 2019 11:46:47 +0300
Subject: Proposal: add indexed map and traverse to Data.List
In-Reply-To: <CAMgWh9uuxAm87z_eJhV7RbkHwMQkoTnGQLFagxeVtzxfvc21LQ@mail.gmail.com>
References: <CAMgWh9uuxAm87z_eJhV7RbkHwMQkoTnGQLFagxeVtzxfvc21LQ@mail.gmail.com>
Message-ID: <CAMdbBiFuvquS5oto9+mkrqdUm_QAB8JLr1MQ2aVQWFAP3TM27Q@mail.gmail.com>

I want to point out that there already exist Haskell package `ilist` that
provides indexed versions of each function for the list from `base`:

* http://hackage.haskell.org/package/ilist

This package comes with optimized implementations and custom fusion rules.
For example `mapWithIndex` is called `imap` and is implemented like this:

{- |/Subject to fusion./-}imap :: (Int -> a -> b) -> [a] -> [b]imap f
ls = go 0# ls  where    go i (x:xs) = f (I# i) x : go (i +# 1#) xs
go _ _ = []{-# NOINLINE [1] imap #-}

imapFB  :: (b -> t -> t) -> (Int -> a -> b) -> a -> (Int# -> t) ->
Int# -> timapFB c f = \x r k -> f (I# k) x `c` r (k +# 1#){-# INLINE
[0] imapFB #-}{-# RULES"imap"       [~1] forall f xs.    imap f xs =
build (\c n -> foldr (imapFB c f) (\_ -> n) xs 0#)"imapList"   [1]
forall f xs.    foldr (imapFB (:) f) (\_ -> []) xs 0# = imap f xs  #-}


I'm not trying to say that we shouldn't have `mapWithIndex` in `base`. But
the implementation for lists already exists and the inspiration about the
implementation can be taken from it.


On Sat, Aug 17, 2019 at 9:17 AM David Feuer <david.feuer at gmail.com> wrote:

> mapWithIndex :: (Int -> a -> b) -> [a] -> [b]
> mapWithIndex f = zipWith f [0..]
>
> traverseWithIndex :: Applicative f => (Int -> a -> f b) -> [a] -> f [b]
> traverseWithIndex f = sequenceA . mapWithIndex
>
> The real implementation of mapWithIndex (and therefore of
> traverseWithIndex) can be a "good consumer" for list fusion. mapWithIndex
> can be a "good producer" as well (which the naive implementation already
> accomplishes).
>
> Similar functions (with these or similar names) are already common in
> packages like vector, containers, unordered-containers, and primitive.
>
> A more general function would merge zipping with unfolding:
>
> zipWithUnfoldr :: (a -> b -> c) -> (s -> Maybe (b, s)) -> [a] -> s -> [c]
> zipWithUnfoldr f g as s = zipWith f as (unfoldr g s)
>
> But this doesn't seem like the friendliest or most obvious user interface,
> so I am not proposing to add it to base.
> _______________________________________________
> 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/20190817/388384cc/attachment.html>

From chessai1996 at gmail.com  Sat Aug 17 19:58:47 2019
From: chessai1996 at gmail.com (chessai .)
Date: Sat, 17 Aug 2019 21:58:47 +0200
Subject: Proposal: add indexed map and traverse to Data.List
In-Reply-To: <CAMdbBiFuvquS5oto9+mkrqdUm_QAB8JLr1MQ2aVQWFAP3TM27Q@mail.gmail.com>
References: <CAMgWh9uuxAm87z_eJhV7RbkHwMQkoTnGQLFagxeVtzxfvc21LQ@mail.gmail.com>
 <CAMdbBiFuvquS5oto9+mkrqdUm_QAB8JLr1MQ2aVQWFAP3TM27Q@mail.gmail.com>
Message-ID: <CAD34_kLtHPs1goiwHi1ZFs0yhj2S1Pky0u7KZH6RGi0WjypZLA@mail.gmail.com>

I have wanted this for a while, and would prefer imap/itraverse as names.
Iirc this is how the similar functions in vector are named

On Sat, Aug 17, 2019, 10:47 AM Dmitriy Kovanikov <kovanikov at gmail.com>
wrote:

> I want to point out that there already exist Haskell package `ilist` that
> provides indexed versions of each function for the list from `base`:
>
> * http://hackage.haskell.org/package/ilist
>
> This package comes with optimized implementations and custom fusion rules.
> For example `mapWithIndex` is called `imap` and is implemented like this:
>
> {- |/Subject to fusion./-}imap :: (Int -> a -> b) -> [a] -> [b]imap f ls = go 0# ls  where    go i (x:xs) = f (I# i) x : go (i +# 1#) xs    go _ _ = []{-# NOINLINE [1] imap #-}
>
> imapFB  :: (b -> t -> t) -> (Int -> a -> b) -> a -> (Int# -> t) -> Int# -> timapFB c f = \x r k -> f (I# k) x `c` r (k +# 1#){-# INLINE [0] imapFB #-}{-# RULES"imap"       [~1] forall f xs.    imap f xs = build (\c n -> foldr (imapFB c f) (\_ -> n) xs 0#)"imapList"   [1]  forall f xs.    foldr (imapFB (:) f) (\_ -> []) xs 0# = imap f xs  #-}
>
>
> I'm not trying to say that we shouldn't have `mapWithIndex` in `base`. But
> the implementation for lists already exists and the inspiration about the
> implementation can be taken from it.
>
>
> On Sat, Aug 17, 2019 at 9:17 AM David Feuer <david.feuer at gmail.com> wrote:
>
>> mapWithIndex :: (Int -> a -> b) -> [a] -> [b]
>> mapWithIndex f = zipWith f [0..]
>>
>> traverseWithIndex :: Applicative f => (Int -> a -> f b) -> [a] -> f [b]
>> traverseWithIndex f = sequenceA . mapWithIndex
>>
>> The real implementation of mapWithIndex (and therefore of
>> traverseWithIndex) can be a "good consumer" for list fusion. mapWithIndex
>> can be a "good producer" as well (which the naive implementation already
>> accomplishes).
>>
>> Similar functions (with these or similar names) are already common in
>> packages like vector, containers, unordered-containers, and primitive.
>>
>> A more general function would merge zipping with unfolding:
>>
>> zipWithUnfoldr :: (a -> b -> c) -> (s -> Maybe (b, s)) -> [a] -> s -> [c]
>> zipWithUnfoldr f g as s = zipWith f as (unfoldr g s)
>>
>> But this doesn't seem like the friendliest or most obvious user
>> interface, so I am not proposing to add it to base.
>> _______________________________________________
>> 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/20190817/2537d243/attachment.html>

From eacameron at gmail.com  Sat Aug 17 20:08:13 2019
From: eacameron at gmail.com (Elliot Cameron)
Date: Sat, 17 Aug 2019 16:08:13 -0400
Subject: Proposal: add indexed map and traverse to Data.List
In-Reply-To: <CAD34_kLtHPs1goiwHi1ZFs0yhj2S1Pky0u7KZH6RGi0WjypZLA@mail.gmail.com>
References: <CAMgWh9uuxAm87z_eJhV7RbkHwMQkoTnGQLFagxeVtzxfvc21LQ@mail.gmail.com>
 <CAMdbBiFuvquS5oto9+mkrqdUm_QAB8JLr1MQ2aVQWFAP3TM27Q@mail.gmail.com>
 <CAD34_kLtHPs1goiwHi1ZFs0yhj2S1Pky0u7KZH6RGi0WjypZLA@mail.gmail.com>
Message-ID: <CANPxu=z0UO+Fo+E=BZtoSKpXsGSLSU_2DZchqJFxwgsn6U7dKA@mail.gmail.com>

As long as the names are in Data.List I don't care as much. But these will
clash with the same names in lens which is very commonly imported
unqualified.

On Sat, Aug 17, 2019 at 3:59 PM chessai . <chessai1996 at gmail.com> wrote:

> I have wanted this for a while, and would prefer imap/itraverse as names.
> Iirc this is how the similar functions in vector are named
>
> On Sat, Aug 17, 2019, 10:47 AM Dmitriy Kovanikov <kovanikov at gmail.com>
> wrote:
>
>> I want to point out that there already exist Haskell package `ilist` that
>> provides indexed versions of each function for the list from `base`:
>>
>> * http://hackage.haskell.org/package/ilist
>>
>> This package comes with optimized implementations and custom fusion
>> rules. For example `mapWithIndex` is called `imap` and is implemented like
>> this:
>>
>> {- |/Subject to fusion./-}imap :: (Int -> a -> b) -> [a] -> [b]imap f ls = go 0# ls  where    go i (x:xs) = f (I# i) x : go (i +# 1#) xs    go _ _ = []{-# NOINLINE [1] imap #-}
>>
>> imapFB  :: (b -> t -> t) -> (Int -> a -> b) -> a -> (Int# -> t) -> Int# -> timapFB c f = \x r k -> f (I# k) x `c` r (k +# 1#){-# INLINE [0] imapFB #-}{-# RULES"imap"       [~1] forall f xs.    imap f xs = build (\c n -> foldr (imapFB c f) (\_ -> n) xs 0#)"imapList"   [1]  forall f xs.    foldr (imapFB (:) f) (\_ -> []) xs 0# = imap f xs  #-}
>>
>>
>> I'm not trying to say that we shouldn't have `mapWithIndex` in `base`.
>> But the implementation for lists already exists and the inspiration about
>> the implementation can be taken from it.
>>
>>
>> On Sat, Aug 17, 2019 at 9:17 AM David Feuer <david.feuer at gmail.com>
>> wrote:
>>
>>> mapWithIndex :: (Int -> a -> b) -> [a] -> [b]
>>> mapWithIndex f = zipWith f [0..]
>>>
>>> traverseWithIndex :: Applicative f => (Int -> a -> f b) -> [a] -> f [b]
>>> traverseWithIndex f = sequenceA . mapWithIndex
>>>
>>> The real implementation of mapWithIndex (and therefore of
>>> traverseWithIndex) can be a "good consumer" for list fusion. mapWithIndex
>>> can be a "good producer" as well (which the naive implementation already
>>> accomplishes).
>>>
>>> Similar functions (with these or similar names) are already common in
>>> packages like vector, containers, unordered-containers, and primitive.
>>>
>>> A more general function would merge zipping with unfolding:
>>>
>>> zipWithUnfoldr :: (a -> b -> c) -> (s -> Maybe (b, s)) -> [a] -> s -> [c]
>>> zipWithUnfoldr f g as s = zipWith f as (unfoldr g s)
>>>
>>> But this doesn't seem like the friendliest or most obvious user
>>> interface, so I am not proposing to add it to base.
>>> _______________________________________________
>>> 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/20190817/82b694f5/attachment.html>

From Henrik.Nilsson at nottingham.ac.uk  Sun Aug 18 14:58:20 2019
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Sun, 18 Aug 2019 15:58:20 +0100
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
Message-ID: <5D59678C.6030003@exmail.nottingham.ac.uk>

Hi,

On 08/13/2019 11:56 PM, Herbert Valerio Riedel wrote:
> But we already have at least two monomorphic variants to express this
> with Haskell's concise native syntax and vocabulary which has by
> design a preferential treatment of lists (it was considered even more
> important than type-sigs so that we got the `:` cons operator for
> lists and the `::` for type-sig annotations) -- so let's not try to
> fight Haskell's core idioms by hiding them behind some trivial
> additional redundant synonyms! I still fail to see the actual
> *technical*  problem being solved by the original proposal asking to
> add yet another, wordy way to construct single-item-lists.

To me, the main argument for "singleton" is that of consistency with
other container types. But, on balance, I do agree with Herbert
and others: operator sections is a core Haskell idiom, and (:[]) is an 
age-old and obvious instance: even beginner Haskell programmers will be
very familiar with (:) for list construction, and along with the basic
arithmetic operators, it is definitely one of the operators most
familiar to Haskell programmers.

So -1 from me.

/Henrik




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.





From alexandre.fmp.esteves at gmail.com  Sun Aug 18 15:46:40 2019
From: alexandre.fmp.esteves at gmail.com (Alexandre Esteves)
Date: Sun, 18 Aug 2019 16:46:40 +0100
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <5D59678C.6030003@exmail.nottingham.ac.uk>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
Message-ID: <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>

If the choice is between adding List.singleton or not, I vote for adding it.
The robot-ninja-monkey-gorilla-whathaveyou operator always causes me to do
a double take, and I'm actually displeased with there being special syntax
for `List` alone - I don't see any special syntax for `Set/Map`, or
`Either`, which is even more fundamental, and on pair with tuples.

But I'd actually prefer a singleton *method*. It seems a frequent point of
debate is single-element-intent vs polymorphic-ness. I'd like to note that
they're not mutually exclusive (whether we end up with best of both worlds
or worst is up for discussion).
When I think of a container of *x*, I think of some data structure with *x*
values inside. Now, they need to be stored/organized/structured *somehow*,
and there's a distinction here:
- some containers require *each* element to be paired with it's
index/key/location (e.g. Map, HashMap, (->))
- some containers build the entire structure based on a single
value/dictionary *which can be known ahead of time, before any values are
provided* (e.g. *Set* uses *Ord*, *HashSet* uses *Hashable*, *List*
trivially uses the empty constraint *()*)

For the second case, we can conceive of a *fromList* function (left and
right inverse of *toList*), which then gives us *singleton = fromList .
(:[])*
Something like:

-- contrast with
https://hackage.haskell.org/package/semigroupoids-5.3.2/docs/Data-Semigroup-Foldable.html#t:Foldable1
class Unfoldable1 c a where
  fromNonEmpty :: NonEmpty a -> c a

  singleton :: a -> c a
  singleton = fromNonEmptyList . (:|[]) -- moustached gorilla operator

-- constrast with Foldable
class Unfoldable1 c a => Unfoldable c a where
  fromList :: [a] -> c a

  unfoldr :: (b -> Maybe (a, b)) -> b -> c a
  unfoldr f = fromList . Data.List.unfoldr f

instance Unfoldable1 [] a where
  fromNonEmpty = toList
instance Unfoldable  [] a where
  fromList = id

instance Unfoldable1 NonEmpty a where
  fromNonEmpty = id

instance Ord a => Unfoldable1 Set a where
  fromNonEmpty = fromList . toList
instance Ord a => Unfoldable Set a where
  fromList = Set.fromList

instance (Eq a, Hashable a) => Unfoldable1 HashSet a where
  fromNonEmpty = fromList . toList
instance (Eq a, Hashable a) => Unfoldable HashSet a where
  fromList = HashSet.fromList


On Sun, Aug 18, 2019 at 3:58 PM Henrik Nilsson <
Henrik.Nilsson at nottingham.ac.uk> wrote:

> Hi,
>
> On 08/13/2019 11:56 PM, Herbert Valerio Riedel wrote:
> > But we already have at least two monomorphic variants to express this
> > with Haskell's concise native syntax and vocabulary which has by
> > design a preferential treatment of lists (it was considered even more
> > important than type-sigs so that we got the `:` cons operator for
> > lists and the `::` for type-sig annotations) -- so let's not try to
> > fight Haskell's core idioms by hiding them behind some trivial
> > additional redundant synonyms! I still fail to see the actual
> > *technical*  problem being solved by the original proposal asking to
> > add yet another, wordy way to construct single-item-lists.
>
> To me, the main argument for "singleton" is that of consistency with
> other container types. But, on balance, I do agree with Herbert
> and others: operator sections is a core Haskell idiom, and (:[]) is an
> age-old and obvious instance: even beginner Haskell programmers will be
> very familiar with (:) for list construction, and along with the basic
> arithmetic operators, it is definitely one of the operators most
> familiar to Haskell programmers.
>
> So -1 from me.
>
> /Henrik
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please contact the sender and delete the email and
> attachment.
>
> Any views or opinions expressed by the author of this email do not
> necessarily reflect the views of the University of Nottingham. Email
> communications with the University of Nottingham may be monitored
> where permitted by law.
>
>
>
>
> _______________________________________________
> 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/20190818/f4dee5f4/attachment.html>

From helmut.schmidt.4711 at gmail.com  Sun Aug 18 16:46:36 2019
From: helmut.schmidt.4711 at gmail.com (Helmut Schmidt)
Date: Sun, 18 Aug 2019 16:46:36 +0000
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
Message-ID: <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>

All these philosophical arguments calling for "consistency" with the
container APIs or that function need words for the human mind to comprehend
seem short-sighted to me. If we were consistent about the proposal itself
we'd also demand to add

  cons = (:)

  empty = []

  toList = id

  fromList = id

to the List module. For consistency's sake!

This reminds me of the famous quote

"A foolish consistency is the hobgoblin of little minds, adored by little
statesmen and philosophers and divines."

In any case I'm -1 on adding singleton or any other consistency-feel-good
names to Data.List





Am So., 18. Aug. 2019 um 15:47 Uhr schrieb Alexandre Esteves <
alexandre.fmp.esteves at gmail.com>:

> If the choice is between adding List.singleton or not, I vote for adding
> it.
> The robot-ninja-monkey-gorilla-whathaveyou operator always causes me to do
> a double take, and I'm actually displeased with there being special syntax
> for `List` alone - I don't see any special syntax for `Set/Map`, or
> `Either`, which is even more fundamental, and on pair with tuples.
>
> But I'd actually prefer a singleton *method*. It seems a frequent point
> of debate is single-element-intent vs polymorphic-ness. I'd like to note
> that they're not mutually exclusive (whether we end up with best of both
> worlds or worst is up for discussion).
> When I think of a container of *x*, I think of some data structure with
> *x* values inside. Now, they need to be stored/organized/structured
> *somehow*, and there's a distinction here:
> - some containers require *each* element to be paired with it's
> index/key/location (e.g. Map, HashMap, (->))
> - some containers build the entire structure based on a single
> value/dictionary *which can be known ahead of time, before any values are
> provided* (e.g. *Set* uses *Ord*, *HashSet* uses *Hashable*, *List*
> trivially uses the empty constraint *()*)
>
> For the second case, we can conceive of a *fromList* function (left and
> right inverse of *toList*), which then gives us *singleton = fromList .
> (:[])*
> Something like:
>
> -- contrast with
> https://hackage.haskell.org/package/semigroupoids-5.3.2/docs/Data-Semigroup-Foldable.html#t:Foldable1
> class Unfoldable1 c a where
>   fromNonEmpty :: NonEmpty a -> c a
>
>   singleton :: a -> c a
>   singleton = fromNonEmptyList . (:|[]) -- moustached gorilla operator
>
> -- constrast with Foldable
> class Unfoldable1 c a => Unfoldable c a where
>   fromList :: [a] -> c a
>
>   unfoldr :: (b -> Maybe (a, b)) -> b -> c a
>   unfoldr f = fromList . Data.List.unfoldr f
>
> instance Unfoldable1 [] a where
>   fromNonEmpty = toList
> instance Unfoldable  [] a where
>   fromList = id
>
> instance Unfoldable1 NonEmpty a where
>   fromNonEmpty = id
>
> instance Ord a => Unfoldable1 Set a where
>   fromNonEmpty = fromList . toList
> instance Ord a => Unfoldable Set a where
>   fromList = Set.fromList
>
> instance (Eq a, Hashable a) => Unfoldable1 HashSet a where
>   fromNonEmpty = fromList . toList
> instance (Eq a, Hashable a) => Unfoldable HashSet a where
>   fromList = HashSet.fromList
>
>
> On Sun, Aug 18, 2019 at 3:58 PM Henrik Nilsson <
> Henrik.Nilsson at nottingham.ac.uk> wrote:
>
>> Hi,
>>
>> On 08/13/2019 11:56 PM, Herbert Valerio Riedel wrote:
>> > But we already have at least two monomorphic variants to express this
>> > with Haskell's concise native syntax and vocabulary which has by
>> > design a preferential treatment of lists (it was considered even more
>> > important than type-sigs so that we got the `:` cons operator for
>> > lists and the `::` for type-sig annotations) -- so let's not try to
>> > fight Haskell's core idioms by hiding them behind some trivial
>> > additional redundant synonyms! I still fail to see the actual
>> > *technical*  problem being solved by the original proposal asking to
>> > add yet another, wordy way to construct single-item-lists.
>>
>> To me, the main argument for "singleton" is that of consistency with
>> other container types. But, on balance, I do agree with Herbert
>> and others: operator sections is a core Haskell idiom, and (:[]) is an
>> age-old and obvious instance: even beginner Haskell programmers will be
>> very familiar with (:) for list construction, and along with the basic
>> arithmetic operators, it is definitely one of the operators most
>> familiar to Haskell programmers.
>>
>> So -1 from me.
>>
>> /Henrik
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please contact the sender and delete the email and
>> attachment.
>>
>> Any views or opinions expressed by the author of this email do not
>> necessarily reflect the views of the University of Nottingham. Email
>> communications with the University of Nottingham may be monitored
>> where permitted by law.
>>
>>
>>
>>
>> _______________________________________________
>> 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/20190818/1f27cd88/attachment.html>

From ollie at ocharles.org.uk  Sun Aug 18 17:16:57 2019
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Sun, 18 Aug 2019 18:16:57 +0100
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
Message-ID: <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>

On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, <helmut.schmidt.4711 at gmail.com>
wrote:

>
> All these philosophical arguments calling for "consistency" with the
> container APIs or that function need words for the human mind to comprehend
> seem short-sighted to me. If we were consistent about the proposal itself
> we'd also demand to add
>
>   cons = (:)
>
>   empty = []
>
>   toList = id
>
>   fromList = id
>

I honestly have no problem with any of these.

Ollie

>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190818/5c92a0df/attachment.html>

From helmut.schmidt.4711 at gmail.com  Sun Aug 18 17:40:33 2019
From: helmut.schmidt.4711 at gmail.com (Helmut Schmidt)
Date: Sun, 18 Aug 2019 17:40:33 +0000
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
Message-ID: <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>

Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles <
ollie at ocharles.org.uk>:

> On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, <
> helmut.schmidt.4711 at gmail.com> wrote:
>
>>
>> All these philosophical arguments calling for "consistency" with the
>> container APIs or that function need words for the human mind to comprehend
>> seem short-sighted to me. If we were consistent about the proposal itself
>> we'd also demand to add
>>
>>   cons = (:)
>>
>>   empty = []
>>
>>   toList = id
>>
>>   fromList = id
>>
>
> I honestly have no problem with any of these.
>

I forgot

    append = (++)

We also need to address another elephant in the room... those pesky tuples
and their special privileged non-wordy syntax!

   pair = (,)

   triple = (,,)

   quadruple = (,,,)

   quituple = (,,,,)

   sextuple = (,,,,,)

   septuble = (,,,,,,)

   octuple = (,,,,,,,)

If Haskell were invented in this century's EU Haskell source code would be
littered with €s instead of $s but then again I wonder why £ wasn't picked.
But I digress. We can kill two birds with one stone here:

   apply = ($)

   strictApply = ($!)

   compose = (.)


It's fun to imagine how code using those definitions would like! But it's
still a -1 for me, sorry!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190818/525e93f8/attachment.html>

From chessai1996 at gmail.com  Sun Aug 18 17:56:39 2019
From: chessai1996 at gmail.com (chessai .)
Date: Sun, 18 Aug 2019 19:56:39 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
Message-ID: <CAD34_kLO2EgSEPaizyTu6L1ZwvukmP4b8cjFhEQc1cCd9u0mdA@mail.gmail.com>

+1

On Sun, Aug 18, 2019, 7:41 PM Helmut Schmidt <helmut.schmidt.4711 at gmail.com>
wrote:

>
>
> Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles <
> ollie at ocharles.org.uk>:
>
>> On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, <
>> helmut.schmidt.4711 at gmail.com> wrote:
>>
>>>
>>> All these philosophical arguments calling for "consistency" with the
>>> container APIs or that function need words for the human mind to comprehend
>>> seem short-sighted to me. If we were consistent about the proposal itself
>>> we'd also demand to add
>>>
>>>   cons = (:)
>>>
>>>   empty = []
>>>
>>>   toList = id
>>>
>>>   fromList = id
>>>
>>
>> I honestly have no problem with any of these.
>>
>
> I forgot
>
>     append = (++)
>
> We also need to address another elephant in the room... those pesky tuples
> and their special privileged non-wordy syntax!
>
>    pair = (,)
>
>    triple = (,,)
>
>    quadruple = (,,,)
>
>    quituple = (,,,,)
>
>    sextuple = (,,,,,)
>
>    septuble = (,,,,,,)
>
>    octuple = (,,,,,,,)
>
> If Haskell were invented in this century's EU Haskell source code would be
> littered with €s instead of $s but then again I wonder why £ wasn't picked.
> But I digress. We can kill two birds with one stone here:
>
>    apply = ($)
>
>    strictApply = ($!)
>
>    compose = (.)
>
>
> It's fun to imagine how code using those definitions would like! But it's
> still a -1 for me, sorry!
>
>
>
> _______________________________________________
> 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/20190818/82c61e0e/attachment.html>

From duke.j.david at gmail.com  Sun Aug 18 20:29:34 2019
From: duke.j.david at gmail.com (David Duke)
Date: Sun, 18 Aug 2019 21:29:34 +0100
Subject: Proposal: Add singleton function to Data.List module
Message-ID: <CAN7OfXT9+i+Mj4N5_XoUDbZMnchv0gu6ObUtay8cNDOxSgH7kQ@mail.gmail.com>

Stepping to one side of the discussion could I just  point out that,
notation is not just about the form of the final program. One of the
claimed strengths and appeals of FP is the opportunity for program
transformation via a useful
repertoire of algebraic law, cf the work on Squiggol, and the numerous
functional pearls by folk including Richard Bird et.al..
This work befits from having concisely-expressed rules that open the road
to manipulation - long-winded
identifiers suitable for large libraries are not necessarily ideal for
algebraic
manipulation. Ye you could treat the two as separate entities, But a
pleasant feature of Haskell is the ability to work with the notation both
for developmemt and final program.

Going back to the original proposal, I'm not bothered, I would probably
just ignore a singleton library.  However I'm -1 on philosophical grounds.
I'm used to teaching FP to undergrads and half the battle is encouraging
people to think functionally, to
make use of the underlying mathematics and computational model rather than
transliterate <insert your favourite 'bete noir'> into Haskell. That means
thinking of building programs from
functional fragments combined by suitable glue, and appreciating that data
constructors can be used
as functions Yes it takes beginner's time to recognise some of the
patterns,  and (:[] is just one such example(when the light dawns,
the transformation is rewarding. I've lost count of the number of jaws I've
had to pick off the floor :)

So I don't want to make a mountain out of a molehill. If it will really
improve programmers'
lives then okay, So far I' not convinced, and but in fretting over final
code can we please not   lose sight of the 'bigger picture' and challenges..


-- 
David Duke

E:duke.j.david at gmail.com
W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190818/00d27f99/attachment.html>

From andreas.abel at ifi.lmu.de  Mon Aug 19 08:16:03 2019
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Mon, 19 Aug 2019 10:16:03 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
Message-ID: <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>

Helmut, do you actually know the container APIs?

Show me cons and append in Data.Set!

On 2019-08-18 19:40, Helmut Schmidt wrote:
> 
> 
> Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles 
> <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
> 
>     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>     <helmut.schmidt.4711 at gmail.com
>     <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
> 
> 
>         All these philosophical arguments calling for "consistency" with
>         the container APIs or that function need words for the human
>         mind to comprehend seem short-sighted to me. If we were
>         consistent about the proposal itself we'd also demand to add
> 
>            cons = (:)
> 
>            empty = []
> 
>            toList = id
> 
>            fromList = id
> 
> 
>     I honestly have no problem with any of these.
> 
> 
> I forgot
> 
>      append = (++)
> 
> We also need to address another elephant in the room... those pesky 
> tuples and their special privileged non-wordy syntax!
> 
>     pair = (,)
> 
>     triple = (,,)
> 
>     quadruple = (,,,)
> 
>     quituple = (,,,,)
> 
>     sextuple = (,,,,,)
> 
>     septuble = (,,,,,,)
> 
>     octuple = (,,,,,,,)
> 
> If Haskell were invented in this century's EU Haskell source code would 
> be littered with €s instead of $s but then again I wonder why £ wasn't 
> picked. But I digress. We can kill two birds with one stone here:
> 
>     apply = ($)
> 
>     strictApply = ($!)
> 
>     compose = (.)
> 
> 
> It's fun to imagine how code using those definitions would like! But 
> it's still a -1 for me, sorry!
> 
> 
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> 

From helmut.schmidt.4711 at gmail.com  Mon Aug 19 10:38:45 2019
From: helmut.schmidt.4711 at gmail.com (Helmut Schmidt)
Date: Mon, 19 Aug 2019 10:38:45 +0000
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
Message-ID: <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>

Andreas, you seem to be mistaken there'd only be one container API? But
there's several container APIs besides "Data.Set" which provide some
collection of elements!

https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons

https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append

https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons

https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append

http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append

Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <
andreas.abel at ifi.lmu.de>:

> Helmut, do you actually know the container APIs?
>
> Show me cons and append in Data.Set!
>
> On 2019-08-18 19:40, Helmut Schmidt wrote:
> >
> >
> > Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles
> > <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
> >
> >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
> >     <helmut.schmidt.4711 at gmail.com
> >     <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
> >
> >
> >         All these philosophical arguments calling for "consistency" with
> >         the container APIs or that function need words for the human
> >         mind to comprehend seem short-sighted to me. If we were
> >         consistent about the proposal itself we'd also demand to add
> >
> >            cons = (:)
> >
> >            empty = []
> >
> >            toList = id
> >
> >            fromList = id
> >
> >
> >     I honestly have no problem with any of these.
> >
> >
> > I forgot
> >
> >      append = (++)
> >
> > We also need to address another elephant in the room... those pesky
> > tuples and their special privileged non-wordy syntax!
> >
> >     pair = (,)
> >
> >     triple = (,,)
> >
> >     quadruple = (,,,)
> >
> >     quituple = (,,,,)
> >
> >     sextuple = (,,,,,)
> >
> >     septuble = (,,,,,,)
> >
> >     octuple = (,,,,,,,)
> >
> > If Haskell were invented in this century's EU Haskell source code would
> > be littered with €s instead of $s but then again I wonder why £ wasn't
> > picked. But I digress. We can kill two birds with one stone here:
> >
> >     apply = ($)
> >
> >     strictApply = ($!)
> >
> >     compose = (.)
> >
> >
> > It's fun to imagine how code using those definitions would like! But
> > it's still a -1 for me, sorry!
> >
> >
> >
> >
> > _______________________________________________
> > 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/20190819/580ca1e2/attachment.html>

From taylor at fausak.me  Tue Aug 20 01:24:18 2019
From: taylor at fausak.me (Taylor Fausak)
Date: Mon, 19 Aug 2019 21:24:18 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
Message-ID: <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>

It has been a week since I submitted my proposal. During that time, 28 people voted, with 16 expressing approval and 12 expressing disapproval. To everyone that voted so far: Thank you! You made for interesting discussion.

I still feel that Haskell would be improved by the addition of a `singleton` function to the `Data.List` module. (And also `Data.List.NonEmpty`, even though that wasn't part of my original proposal.) I would be happy to open a merge request adding code, tests, and documentation. 

I haven't done so yet because I don't know what the next steps are. Can someone from the CLC tell me how an official approval or rejection can be reached, and how long that might take? Thanks!

On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:
> 
> Andreas, you seem to be mistaken there'd only be one container API? But there's several container APIs besides "Data.Set" which provide some collection of elements!
> 
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons
> 
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append
> 
> 
> 
> 
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons
> 
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append
> 
> http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons
> 
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons
> 
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append
> 
> Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <andreas.abel at ifi.lmu.de>:
>> Helmut, do you actually know the container APIs?
>> 
>>  Show me cons and append in Data.Set!
>> 
>>  On 2019-08-18 19:40, Helmut Schmidt wrote:
>>  > 
>>  > 
>>  > Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles 
>>  > <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
>>  > 
>>  > On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>>  > <helmut.schmidt.4711 at gmail.com
>>  > <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
>>  > 
>>  > 
>>  > All these philosophical arguments calling for "consistency" with
>>  > the container APIs or that function need words for the human
>>  > mind to comprehend seem short-sighted to me. If we were
>>  > consistent about the proposal itself we'd also demand to add
>>  > 
>>  > cons = (:)
>>  > 
>>  > empty = []
>>  > 
>>  > toList = id
>>  > 
>>  > fromList = id
>>  > 
>>  > 
>>  > I honestly have no problem with any of these.
>>  > 
>>  > 
>>  > I forgot
>>  > 
>>  > append = (++)
>>  > 
>>  > We also need to address another elephant in the room... those pesky 
>>  > tuples and their special privileged non-wordy syntax!
>>  > 
>>  > pair = (,)
>>  > 
>>  > triple = (,,)
>>  > 
>>  > quadruple = (,,,)
>>  > 
>>  > quituple = (,,,,)
>>  > 
>>  > sextuple = (,,,,,)
>>  > 
>>  > septuble = (,,,,,,)
>>  > 
>>  > octuple = (,,,,,,,)
>>  > 
>>  > If Haskell were invented in this century's EU Haskell source code would 
>>  > be littered with €s instead of $s but then again I wonder why £ wasn't 
>>  > picked. But I digress. We can kill two birds with one stone here:
>>  > 
>>  > apply = ($)
>>  > 
>>  > strictApply = ($!)
>>  > 
>>  > compose = (.)
>>  > 
>>  > 
>>  > It's fun to imagine how code using those definitions would like! But 
>>  > it's still a -1 for me, sorry!
>>  > 
>>  > 
>>  > 
>>  > 
>>  > _______________________________________________
>>  > 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/20190819/baabceda/attachment.html>

From j0villarreal at yahoo.com  Tue Aug 20 06:16:46 2019
From: j0villarreal at yahoo.com (John Villarreal)
Date: Tue, 20 Aug 2019 06:16:46 +0000 (UTC)
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
Message-ID: <928259820.10375274.1566281806455@mail.yahoo.com>

 
I guess it's actually 13 people expressing disapproval and I'm -1 on this proposal as well. When I learned Haskell our programming exercises revolved heavily around manipulating and transforming lists. I never felt the urge to use "singleton" as there were always ways to express this more directly in an obvious way. In fact I would be rather confused to see code operating on lists using a noisy "singleton" function and maybe even consider it a code-smell.

   On Monday, 19 August 2019, 18:24:41 GMT-7, Taylor Fausak <taylor at fausak.me> wrote:  
 
 #yiv7779135445 p.yiv7779135445MsoNormal, #yiv7779135445 p.yiv7779135445MsoNoSpacing{margin:0;}It has been a week since I submitted my proposal. During that time, 28 people voted, with 16 expressing approval and 12 expressing disapproval. To everyone that voted so far: Thank you! You made for interesting discussion.

I still feel that Haskell would be improved by the addition of a `singleton` function to the `Data.List` module. (And also `Data.List.NonEmpty`, even though that wasn't part of my original proposal.) I would be happy to open a merge request adding code, tests, and documentation. 

I haven't done so yet because I don't know what the next steps are. Can someone from the CLC tell me how an official approval or rejection can be reached, and how long that might take? Thanks!

On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:


Andreas, you seem to be mistaken there'd only be one container API? But there's several container APIs besides "Data.Set" which provide some collection of elements!

https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons

https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append




https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons

https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append

http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append

Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <andreas.abel at ifi.lmu.de>:

Helmut, do you actually know the container APIs?
 
 Show me cons and append in Data.Set!
 
 On 2019-08-18 19:40, Helmut Schmidt wrote:
 > 
 > 
 > Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles 
 > <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
 > 
 >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
 >     <helmut.schmidt.4711 at gmail.com
 >     <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
 > 
 > 
 >         All these philosophical arguments calling for "consistency" with
 >         the container APIs or that function need words for the human
 >         mind to comprehend seem short-sighted to me. If we were
 >         consistent about the proposal itself we'd also demand to add
 > 
 >            cons = (:)
 > 
 >            empty = []
 > 
 >            toList = id
 > 
 >            fromList = id
 > 
 > 
 >     I honestly have no problem with any of these.
 > 
 > 
 > I forgot
 > 
 >      append = (++)
 > 
 > We also need to address another elephant in the room... those pesky 
 > tuples and their special privileged non-wordy syntax!
 > 
 >     pair = (,)
 > 
 >     triple = (,,)
 > 
 >     quadruple = (,,,)
 > 
 >     quituple = (,,,,)
 > 
 >     sextuple = (,,,,,)
 > 
 >     septuble = (,,,,,,)
 > 
 >     octuple = (,,,,,,,)
 > 
 > If Haskell were invented in this century's EU Haskell source code would 
 > be littered with €s instead of $s but then again I wonder why £ wasn't 
 > picked. But I digress. We can kill two birds with one stone here:
 > 
 >     apply = ($)
 > 
 >     strictApply = ($!)
 > 
 >     compose = (.)
 > 
 > 
 > It's fun to imagine how code using those definitions would like! But 
 > it's still a -1 for me, sorry!
 > 
 > 
 > 
 > 
 > _______________________________________________
 > 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/20190820/6e186710/attachment.html>

From newhoggy at gmail.com  Tue Aug 20 06:36:31 2019
From: newhoggy at gmail.com (John Ky)
Date: Tue, 20 Aug 2019 08:36:31 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <928259820.10375274.1566281806455@mail.yahoo.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <928259820.10375274.1566281806455@mail.yahoo.com>
Message-ID: <CAMB4o-C9NL6rJTeRd-ee87G2SiYYGtybo7C0mSGDouEJ=TBN6A@mail.gmail.com>

My wish for Haskell is that it had a standard library that wasn't all tied
up in base so that it could be independent of the compiler version, be
easier to contribute to and would be structured so as to cater to those who
want minimalism as well as those who want consistency/comprehensiveness.

Not sure where that puts me on the -1 to +1 scale.

On Tue, 20 Aug 2019 at 08:17, John Villarreal via Libraries <
libraries at haskell.org> wrote:

>
> I guess it's actually 13 people expressing disapproval and I'm -1 on this
> proposal as well. When I learned Haskell our programming exercises revolved
> heavily around manipulating and transforming lists. I never felt the urge
> to use "singleton" as there were always ways to express this more directly
> in an obvious way. In fact I would be rather confused to see code operating
> on lists using a noisy "singleton" function and maybe even consider it a
> code-smell.
>
> On Monday, 19 August 2019, 18:24:41 GMT-7, Taylor Fausak <taylor at fausak.me>
> wrote:
>
>
> It has been a week since I submitted my proposal. During that time, 28
> people voted, with 16 expressing approval and 12 expressing disapproval. To
> everyone that voted so far: Thank you! You made for interesting discussion.
>
> I still feel that Haskell would be improved by the addition of a
> `singleton` function to the `Data.List` module. (And also
> `Data.List.NonEmpty`, even though that wasn't part of my original
> proposal.) I would be happy to open a merge request adding code, tests, and
> documentation.
>
> I haven't done so yet because I don't know what the next steps are. Can
> someone from the CLC tell me how an official approval or rejection can be
> reached, and how long that might take? Thanks!
>
> On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:
>
>
> Andreas, you seem to be mistaken there'd only be one container API? But
> there's several container APIs besides "Data.Set" which provide some
> collection of elements!
>
>
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons
>
>
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append
>
>
>
>
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons
>
>
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append
>
>
> http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons
>
>
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons
>
>
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append
>
> Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <
> andreas.abel at ifi.lmu.de>:
>
> Helmut, do you actually know the container APIs?
>
> Show me cons and append in Data.Set!
>
> On 2019-08-18 19:40, Helmut Schmidt wrote:
> >
> >
> > Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles
> > <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
> >
> >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
> >     <helmut.schmidt.4711 at gmail.com
> >     <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
> >
> >
> >         All these philosophical arguments calling for "consistency" with
> >         the container APIs or that function need words for the human
> >         mind to comprehend seem short-sighted to me. If we were
> >         consistent about the proposal itself we'd also demand to add
> >
> >            cons = (:)
> >
> >            empty = []
> >
> >            toList = id
> >
> >            fromList = id
> >
> >
> >     I honestly have no problem with any of these.
> >
> >
> > I forgot
> >
> >      append = (++)
> >
> > We also need to address another elephant in the room... those pesky
> > tuples and their special privileged non-wordy syntax!
> >
> >     pair = (,)
> >
> >     triple = (,,)
> >
> >     quadruple = (,,,)
> >
> >     quituple = (,,,,)
> >
> >     sextuple = (,,,,,)
> >
> >     septuble = (,,,,,,)
> >
> >     octuple = (,,,,,,,)
> >
> > If Haskell were invented in this century's EU Haskell source code would
> > be littered with €s instead of $s but then again I wonder why £ wasn't
> > picked. But I digress. We can kill two birds with one stone here:
> >
> >     apply = ($)
> >
> >     strictApply = ($!)
> >
> >     compose = (.)
> >
> >
> > It's fun to imagine how code using those definitions would like! But
> > it's still a -1 for me, sorry!
> >
> >
> >
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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/20190820/c504db7e/attachment.html>

From andreas.abel at ifi.lmu.de  Tue Aug 20 09:46:25 2019
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Tue, 20 Aug 2019 11:46:25 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
Message-ID: <3898de29-9521-ef42-c580-455cf52987b8@ifi.lmu.de>

Right, but the ones you quote are all variants of sequences, not 
collections in general.  They have append and cons.  An interface for 
sequences should name these operations uniformly.  However, I would 
restrict the current discussion to construction of collections in 
general, with the interface

   mempty     -- construct an empty collection
   singleton  -- construct a collection with one element
   mappend    -- join two collections

There is a (next to virginal) attempt to define an API for collections at

 
http://hackage.haskell.org/package/collections-api-1.0.0.0/docs/Data-Collections.html

Incidentally, it has

   singleton :: i -> c
   Creates a collection with a single element.

Cheers,
Andreas

On 2019-08-19 12:38, Helmut Schmidt wrote:
> Andreas, you seem to be mistaken there'd only be one container API? But 
> there's several container APIs besides "Data.Set" which provide some 
> collection of elements!
> 
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons
> 
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append
> 
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons
> 
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append
> 
> http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons
> 
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons
> 
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append
> 
> Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel 
> <andreas.abel at ifi.lmu.de <mailto:andreas.abel at ifi.lmu.de>>:
> 
>     Helmut, do you actually know the container APIs?
> 
>     Show me cons and append in Data.Set!
> 
>     On 2019-08-18 19:40, Helmut Schmidt wrote:
>      >
>      >
>      > Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles
>      > <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>
>     <mailto:ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>>:
>      >
>      >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>      >     <helmut.schmidt.4711 at gmail.com
>     <mailto:helmut.schmidt.4711 at gmail.com>
>      >     <mailto:helmut.schmidt.4711 at gmail.com
>     <mailto:helmut.schmidt.4711 at gmail.com>>> wrote:
>      >
>      >
>      >         All these philosophical arguments calling for
>     "consistency" with
>      >         the container APIs or that function need words for the human
>      >         mind to comprehend seem short-sighted to me. If we were
>      >         consistent about the proposal itself we'd also demand to add
>      >
>      >            cons = (:)
>      >
>      >            empty = []
>      >
>      >            toList = id
>      >
>      >            fromList = id
>      >
>      >
>      >     I honestly have no problem with any of these.
>      >
>      >
>      > I forgot
>      >
>      >      append = (++)
>      >
>      > We also need to address another elephant in the room... those pesky
>      > tuples and their special privileged non-wordy syntax!
>      >
>      >     pair = (,)
>      >
>      >     triple = (,,)
>      >
>      >     quadruple = (,,,)
>      >
>      >     quituple = (,,,,)
>      >
>      >     sextuple = (,,,,,)
>      >
>      >     septuble = (,,,,,,)
>      >
>      >     octuple = (,,,,,,,)
>      >
>      > If Haskell were invented in this century's EU Haskell source code
>     would
>      > be littered with €s instead of $s but then again I wonder why £
>     wasn't
>      > picked. But I digress. We can kill two birds with one stone here:
>      >
>      >     apply = ($)
>      >
>      >     strictApply = ($!)
>      >
>      >     compose = (.)
>      >
>      >
>      > It's fun to imagine how code using those definitions would like! But
>      > it's still a -1 for me, sorry!
>      >
>      >
>      >
>      >
>      > _______________________________________________
>      > Libraries mailing list
>      > Libraries at haskell.org <mailto:Libraries at haskell.org>
>      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>      >
> 

From bertram.felgenhauer at googlemail.com  Tue Aug 20 10:44:12 2019
From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer)
Date: Tue, 20 Aug 2019 12:44:12 +0200
Subject: Standard of approval for library submissions (Was: Proposal: Add
 singleton function to Data.List module)
In-Reply-To: <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
References: <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
Message-ID: <20190820104412.GA2226@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>

Taylor Fausak wrote:
> It has been a week since I submitted my proposal. During that time, 28
> people voted, with 16 expressing approval and 12 expressing
> disapproval. To everyone that voted so far: Thank you! You made for
> interesting discussion.

I thought the standard of approval for library proposals was a broad
consensus for adoptation, which we clearly do not have here. It was
supposed to be a reasoned decision based on arguments put forward by
proponents and opponents of the idea. There has always been a tendency
to express agreement or disagreement numerically, but recently these
agreements and disagreements have been treated as a voting system, and
I believe that's an unhealthy trend.

With a simple majority-based straw poll on the mailing list we risk
ending up with a ton of questionable additions to the core libraries
that have a handful of outspoken proponents and nobody who really cares;
the end result will be, predictably, a library full of functions that
nobody ever uses.

In the case of a dispute (which we have here), the decision should be
made by the maintainer(s), i.e. the Core Libraries Committee in this
case. As maintainers, they are also in a better position to address
concerns like consistency (which is hard to obtain by incrementally
adding small functions.)

Perhaps we should also consider that voting takes almost no effort,
whereas composing a coherent argument takes much time and effort.

Overall I believe we should go back to weighing arguments rather than
voting for library proposals.

Cheers,

Bertram

From bertram.felgenhauer at googlemail.com  Tue Aug 20 10:47:29 2019
From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer)
Date: Tue, 20 Aug 2019 12:47:29 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
References: <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
Message-ID: <20190820104729.GB2226@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>

Taylor Fausak wrote:
> It has been a week since I submitted my proposal. During that time, 28
> people voted, with 16 expressing approval and 12 expressing
> disapproval. To everyone that voted so far: Thank you! You made for
> interesting discussion.

I've just written about straw polls in a separate mail...

In the particular case of adding `singleton` to `Data.List`, I don't
believe having `singleton` in Data.List will cause much harm beyond
being yet another synonym to remember when reading other people's code,
and inevitably breaking some code. I can even see the consistency
argument, if one views lists as containers. But to me, lists are,
foremost, iterators. (In fact that's why I usually import Data.List
unqualified, because iterators are so common! So the risk of breaking
code is, to me, real.)

I'm pretty sure I will not use `singleton`, having grown used to all
four of (:[]), \x -> [x], `return`, and lately `pure`. So there's no
benefit in having the function.

(If you're counting votes, that's -1 from me.)

Cheers,

Bertram

From george at wils.online  Wed Aug 21 05:31:43 2019
From: george at wils.online (George Wilson)
Date: Wed, 21 Aug 2019 15:31:43 +1000
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
Message-ID: <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>

Hi Taylor,

I'm on the Core Libraries Committee. Thank you for your proposal.
Regarding the +-1 messages in this thread, they are useful to gauge
community opinion, but they are not votes because the libraries
process is not determined by a vote.

Despite seeming innocuous, the proposed change requires careful
consideration: Data.List is specified by the Haskell Report, so adding
this function would affect the report.
While simple changes to base are typically handled directly by one of
base's maintainers, this change is report-affecting, so it is
"controversial" (as defined in [1]). Hence the CLC is discussing the
proposed change amongst ourselves before a maintainer makes their
decision.

[1] https://wiki.haskell.org/Library_submissions

Cheers,
George





On Tue, 20 Aug 2019 at 11:24, Taylor Fausak <taylor at fausak.me> wrote:
>
> It has been a week since I submitted my proposal. During that time, 28 people voted, with 16 expressing approval and 12 expressing disapproval. To everyone that voted so far: Thank you! You made for interesting discussion.
>
> I still feel that Haskell would be improved by the addition of a `singleton` function to the `Data.List` module. (And also `Data.List.NonEmpty`, even though that wasn't part of my original proposal.) I would be happy to open a merge request adding code, tests, and documentation.
>
> I haven't done so yet because I don't know what the next steps are. Can someone from the CLC tell me how an official approval or rejection can be reached, and how long that might take? Thanks!
>
> On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:
>
>
> Andreas, you seem to be mistaken there'd only be one container API? But there's several container APIs besides "Data.Set" which provide some collection of elements!
>
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons
>
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append
>
>
>
>
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons
>
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append
>
> http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons
>
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons
>
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append
>
> Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <andreas.abel at ifi.lmu.de>:
>
> Helmut, do you actually know the container APIs?
>
> Show me cons and append in Data.Set!
>
> On 2019-08-18 19:40, Helmut Schmidt wrote:
> >
> >
> > Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles
> > <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
> >
> >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
> >     <helmut.schmidt.4711 at gmail.com
> >     <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
> >
> >
> >         All these philosophical arguments calling for "consistency" with
> >         the container APIs or that function need words for the human
> >         mind to comprehend seem short-sighted to me. If we were
> >         consistent about the proposal itself we'd also demand to add
> >
> >            cons = (:)
> >
> >            empty = []
> >
> >            toList = id
> >
> >            fromList = id
> >
> >
> >     I honestly have no problem with any of these.
> >
> >
> > I forgot
> >
> >      append = (++)
> >
> > We also need to address another elephant in the room... those pesky
> > tuples and their special privileged non-wordy syntax!
> >
> >     pair = (,)
> >
> >     triple = (,,)
> >
> >     quadruple = (,,,)
> >
> >     quituple = (,,,,)
> >
> >     sextuple = (,,,,,)
> >
> >     septuble = (,,,,,,)
> >
> >     octuple = (,,,,,,,)
> >
> > If Haskell were invented in this century's EU Haskell source code would
> > be littered with €s instead of $s but then again I wonder why £ wasn't
> > picked. But I digress. We can kill two birds with one stone here:
> >
> >     apply = ($)
> >
> >     strictApply = ($!)
> >
> >     compose = (.)
> >
> >
> > It's fun to imagine how code using those definitions would like! But
> > it's still a -1 for me, sorry!
> >
> >
> >
> >
> > _______________________________________________
> > 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

From nbouscal at gmail.com  Wed Aug 21 10:22:22 2019
From: nbouscal at gmail.com (Nathan Bouscal)
Date: Wed, 21 Aug 2019 11:22:22 +0100
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
Message-ID: <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>

Hi all,

I would strongly encourage anyone inclined to say things like “there's
no benefit
in having the function” to consider reframing the sentiment as “I wouldn’t
benefit from having the function, and don’t understand the benefit others
will gain.” Once you’ve done that reframe, you can notice that there’s a
lack of understanding toward which the appropriate emotional stance is
curiosity, not dismissiveness. A lot of people have clearly expressed in
this thread that they would benefit from this function, and when you assert
as fact that such benefit does not exist, you’re implicitly dismissing and
devaluing their experience.

Independent of any technical merits or readability concerns per se, there
is a signaling aspect to this discussion. Already this thread has been
referenced many times on social media, and it’s sending a very loud signal:
“we don’t want you here”. Not because of the content of the discussion, but
because of its tone. I happen to think that Haskell is a fantastic language
for beginners, and I’ve been watching in real time as potential learners
are deciding it isn’t for them. I’ve also been seeing experienced
Haskellers deciding it’s not worth it to participate in the libraries
process. You can argue as much as you want that people are wrong to get
that signal from this thread, that they’re misinterpreting the comments
here, etc, but none of that changes the outcome. We can do better than this.


On the proposal itself: I’ve been writing Haskell for several years now and
have founded a company that uses Haskell in production, so I’d like to
think I’m at least a step or two beyond “beginner”, and yet I cannot recall
the last time I saw (:[]) in my code or anyone else’s, and seeing it here
caused me to double-take and take a moment to mentally parse it. If that’s
the case for me, I’m sure it must be far worse for an actual beginner.
Building things by composing primitives is good, but if anyone put this
operator into my codebase I’d likely flag it in code review. Readability
isn’t about whether it’s possible to read something, it’s about how easy it
is to read, and for me this operator doesn’t pass that test. Personally I
tend to use pure, but a monomorphic option would be better. I would happily
change to using singleton if it becomes available, and am a +1 on the
proposal for both List and NonEmpty.


Nathan


On Wed, Aug 21, 2019 at 6:32 AM George Wilson <george at wils.online> wrote:

> Hi Taylor,
>
> I'm on the Core Libraries Committee. Thank you for your proposal.
> Regarding the +-1 messages in this thread, they are useful to gauge
> community opinion, but they are not votes because the libraries
> process is not determined by a vote.
>
> Despite seeming innocuous, the proposed change requires careful
> consideration: Data.List is specified by the Haskell Report, so adding
> this function would affect the report.
> While simple changes to base are typically handled directly by one of
> base's maintainers, this change is report-affecting, so it is
> "controversial" (as defined in [1]). Hence the CLC is discussing the
> proposed change amongst ourselves before a maintainer makes their
> decision.
>
> [1] https://wiki.haskell.org/Library_submissions
>
> Cheers,
> George
>
>
>
>
>
> On Tue, 20 Aug 2019 at 11:24, Taylor Fausak <taylor at fausak.me> wrote:
> >
> > It has been a week since I submitted my proposal. During that time, 28
> people voted, with 16 expressing approval and 12 expressing disapproval. To
> everyone that voted so far: Thank you! You made for interesting discussion.
> >
> > I still feel that Haskell would be improved by the addition of a
> `singleton` function to the `Data.List` module. (And also
> `Data.List.NonEmpty`, even though that wasn't part of my original
> proposal.) I would be happy to open a merge request adding code, tests, and
> documentation.
> >
> > I haven't done so yet because I don't know what the next steps are. Can
> someone from the CLC tell me how an official approval or rejection can be
> reached, and how long that might take? Thanks!
> >
> > On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:
> >
> >
> > Andreas, you seem to be mistaken there'd only be one container API? But
> there's several container APIs besides "Data.Set" which provide some
> collection of elements!
> >
> >
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons
> >
> >
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append
> >
> >
> >
> >
> >
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons
> >
> >
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append
> >
> >
> http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons
> >
> >
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons
> >
> >
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append
> >
> > Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <
> andreas.abel at ifi.lmu.de>:
> >
> > Helmut, do you actually know the container APIs?
> >
> > Show me cons and append in Data.Set!
> >
> > On 2019-08-18 19:40, Helmut Schmidt wrote:
> > >
> > >
> > > Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles
> > > <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
> > >
> > >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
> > >     <helmut.schmidt.4711 at gmail.com
> > >     <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
> > >
> > >
> > >         All these philosophical arguments calling for "consistency"
> with
> > >         the container APIs or that function need words for the human
> > >         mind to comprehend seem short-sighted to me. If we were
> > >         consistent about the proposal itself we'd also demand to add
> > >
> > >            cons = (:)
> > >
> > >            empty = []
> > >
> > >            toList = id
> > >
> > >            fromList = id
> > >
> > >
> > >     I honestly have no problem with any of these.
> > >
> > >
> > > I forgot
> > >
> > >      append = (++)
> > >
> > > We also need to address another elephant in the room... those pesky
> > > tuples and their special privileged non-wordy syntax!
> > >
> > >     pair = (,)
> > >
> > >     triple = (,,)
> > >
> > >     quadruple = (,,,)
> > >
> > >     quituple = (,,,,)
> > >
> > >     sextuple = (,,,,,)
> > >
> > >     septuble = (,,,,,,)
> > >
> > >     octuple = (,,,,,,,)
> > >
> > > If Haskell were invented in this century's EU Haskell source code would
> > > be littered with €s instead of $s but then again I wonder why £ wasn't
> > > picked. But I digress. We can kill two birds with one stone here:
> > >
> > >     apply = ($)
> > >
> > >     strictApply = ($!)
> > >
> > >     compose = (.)
> > >
> > >
> > > It's fun to imagine how code using those definitions would like! But
> > > it's still a -1 for me, sorry!
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> _______________________________________________
> 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/20190821/212ddf36/attachment.html>

From simonpj at microsoft.com  Wed Aug 21 12:31:27 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 21 Aug 2019 12:31:27 +0000
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
Message-ID: <VI1PR83MB031902A37C450EA3C3985956ADAA0@VI1PR83MB0319.EURPRD83.prod.outlook.com>

Once you’ve done that reframe, you can notice that there’s a lack of understanding toward which the appropriate emotional stance is curiosity, not dismissiveness. A lot of people have clearly expressed in this thread that they would benefit from this function, and when you assert as fact that such benefit does not exist, you’re implicitly dismissing and devaluing their experience.
I strongly endorse Nathan’s point here.

I think that a lot of the dismissiveness/devaluing is entirely unintentional -- but that does not reduce its harmful effects.   Nathan does us a service by bringing it to consciousness.  As he says, we can do better than this.

I like the emphasis on curiosity.  The GHC Steering Committee has adopted guidelines<https://github.com/ghc-proposals/ghc-proposals/blob/master/GRC.rst> with similar vocabulary.

Simon

From: Libraries <libraries-bounces at haskell.org> On Behalf Of Nathan Bouscal
Sent: 21 August 2019 11:22
To: Haskell Libraries <libraries at haskell.org>
Subject: Re: Proposal: Add singleton function to Data.List module

Hi all,

I would strongly encourage anyone inclined to say things like “there's no benefit in having the function” to consider reframing the sentiment as “I wouldn’t benefit from having the function, and don’t understand the benefit others will gain.” Once you’ve done that reframe, you can notice that there’s a lack of understanding toward which the appropriate emotional stance is curiosity, not dismissiveness. A lot of people have clearly expressed in this thread that they would benefit from this function, and when you assert as fact that such benefit does not exist, you’re implicitly dismissing and devaluing their experience.

Independent of any technical merits or readability concerns per se, there is a signaling aspect to this discussion. Already this thread has been referenced many times on social media, and it’s sending a very loud signal: “we don’t want you here”. Not because of the content of the discussion, but because of its tone. I happen to think that Haskell is a fantastic language for beginners, and I’ve been watching in real time as potential learners are deciding it isn’t for them. I’ve also been seeing experienced Haskellers deciding it’s not worth it to participate in the libraries process. You can argue as much as you want that people are wrong to get that signal from this thread, that they’re misinterpreting the comments here, etc, but none of that changes the outcome. We can do better than this.


On the proposal itself: I’ve been writing Haskell for several years now and have founded a company that uses Haskell in production, so I’d like to think I’m at least a step or two beyond “beginner”, and yet I cannot recall the last time I saw (:[]) in my code or anyone else’s, and seeing it here caused me to double-take and take a moment to mentally parse it. If that’s the case for me, I’m sure it must be far worse for an actual beginner. Building things by composing primitives is good, but if anyone put this operator into my codebase I’d likely flag it in code review. Readability isn’t about whether it’s possible to read something, it’s about how easy it is to read, and for me this operator doesn’t pass that test. Personally I tend to use pure, but a monomorphic option would be better. I would happily change to using singleton if it becomes available, and am a +1 on the proposal for both List and NonEmpty.


Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190821/fabbb163/attachment.html>

From taylor at fausak.me  Wed Aug 21 12:31:41 2019
From: taylor at fausak.me (Taylor Fausak)
Date: Wed, 21 Aug 2019 08:31:41 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
Message-ID: <ea38b66f-be14-477e-b140-67c2a67b6e46@www.fastmail.com>

Thanks for saying that, Nathan! I agree wholeheartedly.

To George and the CLC: I'm disappointed to hear that I inadvertently suggested something that would require changing the Haskell Language Report. It is my understanding that work on the report has more or less stalled [1], and I would hate for this simple addition to be caught in that quagmire.

Your mention of the report encouraged me to look for differences between the current Data.List module and the one specified in the report [2]. Aside from the obvious Foldable/Traversable changes brought by the FTP proposal, it didn't take long to find a difference: the uncons function [3]. I found its source in GHC.List [4], which pointed me to a Trac issue [5], a mailing list thread [6], and a Phabricator differential [7].

I bring this up not because I expect the process to be exactly the same today as it was five years ago, but because the simple addition of the uncons function was accepted without nearly as much discussion. Also it was notably accepted without any mention of the report at all. Has something changed in the meantime, or did I suggest something that hit a nerve with the community?

Regardless, I'm happy to hear that the CLC is considering my proposal among themselves. Is there an expected timeline? (I'm looking for a rough order of magnitude, not an exact date.) Thanks!

1: https://github.com/haskell/rfcs/issues/15
2: https://www.haskell.org/onlinereport/haskell2010/haskellch20.html#x28-22800020
3: https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-List.html#v:uncons
4: https://gitlab.haskell.org/ghc/ghc/blob/83ca42de519cdfa28b38164e90d726034dba768e/libraries/base/GHC/List.hs#L65-72
5: https://gitlab.haskell.org/ghc/ghc/issues/9550
6: https://mail.haskell.org/pipermail/libraries/2014-July/023314.html
7: https://phabricator.haskell.org/D195

On Wed, Aug 21, 2019, at 6:22 AM, Nathan Bouscal wrote:
> Hi all,
> 
> I would strongly encourage anyone inclined to say things like “there's no benefit in having the function” to consider reframing the sentiment as “I wouldn’t benefit from having the function, and don’t understand the benefit others will gain.” Once you’ve done that reframe, you can notice that there’s a lack of understanding toward which the appropriate emotional stance is curiosity, not dismissiveness. A lot of people have clearly expressed in this thread that they would benefit from this function, and when you assert as fact that such benefit does not exist, you’re implicitly dismissing and devaluing their experience. 
> 
> Independent of any technical merits or readability concerns per se, there is a signaling aspect to this discussion. Already this thread has been referenced many times on social media, and it’s sending a very loud signal: “we don’t want you here”. Not because of the content of the discussion, but because of its tone. I happen to think that Haskell is a fantastic language for beginners, and I’ve been watching in real time as potential learners are deciding it isn’t for them. I’ve also been seeing experienced Haskellers deciding it’s not worth it to participate in the libraries process. You can argue as much as you want that people are wrong to get that signal from this thread, that they’re misinterpreting the comments here, etc, but none of that changes the outcome. We can do better than this.
> 
> 
> On the proposal itself: I’ve been writing Haskell for several years now and have founded a company that uses Haskell in production, so I’d like to think I’m at least a step or two beyond “beginner”, and yet I cannot recall the last time I saw (:[]) in my code or anyone else’s, and seeing it here caused me to double-take and take a moment to mentally parse it. If that’s the case for me, I’m sure it must be far worse for an actual beginner. Building things by composing primitives is good, but if anyone put this operator into my codebase I’d likely flag it in code review. Readability isn’t about whether it’s possible to read something, it’s about how easy it is to read, and for me this operator doesn’t pass that test. Personally I tend to use pure, but a monomorphic option would be better. I would happily change to using singleton if it becomes available, and am a +1 on the proposal for both List and NonEmpty.
> 
> 
> Nathan
> 
> 
> On Wed, Aug 21, 2019 at 6:32 AM George Wilson <george at wils.online> wrote:
>> Hi Taylor,
>> 
>>  I'm on the Core Libraries Committee. Thank you for your proposal.
>>  Regarding the +-1 messages in this thread, they are useful to gauge
>>  community opinion, but they are not votes because the libraries
>>  process is not determined by a vote.
>> 
>>  Despite seeming innocuous, the proposed change requires careful
>>  consideration: Data.List is specified by the Haskell Report, so adding
>>  this function would affect the report.
>>  While simple changes to base are typically handled directly by one of
>>  base's maintainers, this change is report-affecting, so it is
>>  "controversial" (as defined in [1]). Hence the CLC is discussing the
>>  proposed change amongst ourselves before a maintainer makes their
>>  decision.
>> 
>>  [1] https://wiki.haskell.org/Library_submissions
>> 
>>  Cheers,
>>  George
>> 
>> 
>> 
>> 
>> 
>>  On Tue, 20 Aug 2019 at 11:24, Taylor Fausak <taylor at fausak.me> wrote:
>>  >
>>  > It has been a week since I submitted my proposal. During that time, 28 people voted, with 16 expressing approval and 12 expressing disapproval. To everyone that voted so far: Thank you! You made for interesting discussion.
>>  >
>>  > I still feel that Haskell would be improved by the addition of a `singleton` function to the `Data.List` module. (And also `Data.List.NonEmpty`, even though that wasn't part of my original proposal.) I would be happy to open a merge request adding code, tests, and documentation.
>>  >
>>  > I haven't done so yet because I don't know what the next steps are. Can someone from the CLC tell me how an official approval or rejection can be reached, and how long that might take? Thanks!
>>  >
>>  > On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:
>>  >
>>  >
>>  > Andreas, you seem to be mistaken there'd only be one container API? But there's several container APIs besides "Data.Set" which provide some collection of elements!
>>  >
>>  > https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons
>>  >
>>  > https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append
>>  >
>>  >
>>  >
>>  >
>>  > https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons
>>  >
>>  > https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append
>>  >
>>  > http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons
>>  >
>>  > https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons
>>  >
>>  > https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append
>>  >
>>  > Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <andreas.abel at ifi.lmu.de>:
>>  >
>>  > Helmut, do you actually know the container APIs?
>>  >
>>  > Show me cons and append in Data.Set!
>>  >
>>  > On 2019-08-18 19:40, Helmut Schmidt wrote:
>>  > >
>>  > >
>>  > > Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles
>>  > > <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
>>  > >
>>  > > On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>>  > > <helmut.schmidt.4711 at gmail.com
>>  > > <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
>>  > >
>>  > >
>>  > > All these philosophical arguments calling for "consistency" with
>>  > > the container APIs or that function need words for the human
>>  > > mind to comprehend seem short-sighted to me. If we were
>>  > > consistent about the proposal itself we'd also demand to add
>>  > >
>>  > > cons = (:)
>>  > >
>>  > > empty = []
>>  > >
>>  > > toList = id
>>  > >
>>  > > fromList = id
>>  > >
>>  > >
>>  > > I honestly have no problem with any of these.
>>  > >
>>  > >
>>  > > I forgot
>>  > >
>>  > > append = (++)
>>  > >
>>  > > We also need to address another elephant in the room... those pesky
>>  > > tuples and their special privileged non-wordy syntax!
>>  > >
>>  > > pair = (,)
>>  > >
>>  > > triple = (,,)
>>  > >
>>  > > quadruple = (,,,)
>>  > >
>>  > > quituple = (,,,,)
>>  > >
>>  > > sextuple = (,,,,,)
>>  > >
>>  > > septuble = (,,,,,,)
>>  > >
>>  > > octuple = (,,,,,,,)
>>  > >
>>  > > If Haskell were invented in this century's EU Haskell source code would
>>  > > be littered with €s instead of $s but then again I wonder why £ wasn't
>>  > > picked. But I digress. We can kill two birds with one stone here:
>>  > >
>>  > > apply = ($)
>>  > >
>>  > > strictApply = ($!)
>>  > >
>>  > > compose = (.)
>>  > >
>>  > >
>>  > > It's fun to imagine how code using those definitions would like! But
>>  > > it's still a -1 for me, sorry!
>>  > >
>>  > >
>>  > >
>>  > >
>>  > > _______________________________________________
>>  > > 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
>>  _______________________________________________
>>  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/20190821/52cc77c1/attachment.html>

From kris.nuttycombe at gmail.com  Wed Aug 21 16:00:37 2019
From: kris.nuttycombe at gmail.com (Kris Nuttycombe)
Date: Wed, 21 Aug 2019 10:00:37 -0600
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <ea38b66f-be14-477e-b140-67c2a67b6e46@www.fastmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
 <ea38b66f-be14-477e-b140-67c2a67b6e46@www.fastmail.com>
Message-ID: <CAHFpbun_pNu3bGU41V-VAkurpM2h=rQ=gcKfq6ORqc8Z_s_9_w@mail.gmail.com>

Since this has remained contentious, I'd like to contribute my +1 to the
argument, and to express my support for the points that Nathan and Matt
have raised. To this point in the discussion, however, I have not seen
raised the perspective that I hold, and so I'm going to add another color
to the bikeshed.

My point of view here is informed by my efforts to teach my children to
program, using Haskell.

In every case where we define a typeclass instance, we write the
implementation of that instance as a number of monomorphic functions. My
position is that these monomorphic functions should always be exported
directly, perhaps from an `.Internal` module.

My preferred way of writing typeclass instances is just this: I create two
modules, `Foo.Bar` and `Foo.Bar.Internal`. `Foo.Bar` is used only to
selectively reexport from `Foo.Bar.Internal`, which is where the relevant
types and typeclass instances are defined. For each typeclass method to be
implemented, I define a top-level monomorphic function, and this function
is used in the implementation of the instance; in this case, it would look
like:

module Data.List.Internal where
  ...

  singleton :: x -> [x]
  singleton x = [x]

instance Applicative [] where
  pure = singleton
  ...

When followed consistently, this gives the end user the greatest
flexibility in choosing whether to use the monomorphic version (in a
context where they want the compiler to alert them if the type changes) or
the polymorphic one. I dearly wish, for example, that this approach were
followed in `Data.Time.Clock`, for example, where a good deal of the
important functionality is awkwardly hidden in `Num` and `Integral`
instances (which, as an aside, are highly inappropriate).

In conclusion, I think that the proposal for Data.List.singleton is a good
one - I just wish that it went a great deal further.

Kris

On Wed, Aug 21, 2019 at 6:32 AM Taylor Fausak <taylor at fausak.me> wrote:

> Thanks for saying that, Nathan! I agree wholeheartedly.
>
> To George and the CLC: I'm disappointed to hear that I inadvertently
> suggested something that would require changing the Haskell Language
> Report. It is my understanding that work on the report has more or less
> stalled [1], and I would hate for this simple addition to be caught in that
> quagmire.
>
> Your mention of the report encouraged me to look for differences between
> the current Data.List module and the one specified in the report [2]. Aside
> from the obvious Foldable/Traversable changes brought by the FTP proposal,
> it didn't take long to find a difference: the uncons function [3]. I found
> its source in GHC.List [4], which pointed me to a Trac issue [5], a mailing
> list thread [6], and a Phabricator differential [7].
>
> I bring this up not because I expect the process to be exactly the same
> today as it was five years ago, but because the simple addition of the
> uncons function was accepted without nearly as much discussion. Also it was
> notably accepted without any mention of the report at all. Has something
> changed in the meantime, or did I suggest something that hit a nerve with
> the community?
>
> Regardless, I'm happy to hear that the CLC is considering my proposal
> among themselves. Is there an expected timeline? (I'm looking for a rough
> order of magnitude, not an exact date.) Thanks!
>
> 1: https://github.com/haskell/rfcs/issues/15
> 2:
> https://www.haskell.org/onlinereport/haskell2010/haskellch20.html#x28-22800020
> 3:
> https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-List.html#v:uncons
> 4:
> https://gitlab.haskell.org/ghc/ghc/blob/83ca42de519cdfa28b38164e90d726034dba768e/libraries/base/GHC/List.hs#L65-72
> 5: https://gitlab.haskell.org/ghc/ghc/issues/9550
> 6: https://mail.haskell.org/pipermail/libraries/2014-July/023314.html
> 7: https://phabricator.haskell.org/D195
>
> On Wed, Aug 21, 2019, at 6:22 AM, Nathan Bouscal wrote:
>
> Hi all,
>
> I would strongly encourage anyone inclined to say things like “there's no benefit
> in having the function” to consider reframing the sentiment as “I wouldn’t
> benefit from having the function, and don’t understand the benefit others
> will gain.” Once you’ve done that reframe, you can notice that there’s a
> lack of understanding toward which the appropriate emotional stance is
> curiosity, not dismissiveness. A lot of people have clearly expressed in
> this thread that they would benefit from this function, and when you assert
> as fact that such benefit does not exist, you’re implicitly dismissing and
> devaluing their experience.
>
> Independent of any technical merits or readability concerns per se, there
> is a signaling aspect to this discussion. Already this thread has been
> referenced many times on social media, and it’s sending a very loud signal:
> “we don’t want you here”. Not because of the content of the discussion, but
> because of its tone. I happen to think that Haskell is a fantastic language
> for beginners, and I’ve been watching in real time as potential learners
> are deciding it isn’t for them. I’ve also been seeing experienced
> Haskellers deciding it’s not worth it to participate in the libraries
> process. You can argue as much as you want that people are wrong to get
> that signal from this thread, that they’re misinterpreting the comments
> here, etc, but none of that changes the outcome. We can do better than this.
>
>
> On the proposal itself: I’ve been writing Haskell for several years now
> and have founded a company that uses Haskell in production, so I’d like to
> think I’m at least a step or two beyond “beginner”, and yet I cannot recall
> the last time I saw (:[]) in my code or anyone else’s, and seeing it here
> caused me to double-take and take a moment to mentally parse it. If that’s
> the case for me, I’m sure it must be far worse for an actual beginner.
> Building things by composing primitives is good, but if anyone put this
> operator into my codebase I’d likely flag it in code review. Readability
> isn’t about whether it’s possible to read something, it’s about how easy it
> is to read, and for me this operator doesn’t pass that test. Personally I
> tend to use pure, but a monomorphic option would be better. I would happily
> change to using singleton if it becomes available, and am a +1 on the
> proposal for both List and NonEmpty.
>
>
> Nathan
>
>
> On Wed, Aug 21, 2019 at 6:32 AM George Wilson <george at wils.online> wrote:
>
> Hi Taylor,
>
> I'm on the Core Libraries Committee. Thank you for your proposal.
> Regarding the +-1 messages in this thread, they are useful to gauge
> community opinion, but they are not votes because the libraries
> process is not determined by a vote.
>
> Despite seeming innocuous, the proposed change requires careful
> consideration: Data.List is specified by the Haskell Report, so adding
> this function would affect the report.
> While simple changes to base are typically handled directly by one of
> base's maintainers, this change is report-affecting, so it is
> "controversial" (as defined in [1]). Hence the CLC is discussing the
> proposed change amongst ourselves before a maintainer makes their
> decision.
>
> [1] https://wiki.haskell.org/Library_submissions
>
> Cheers,
> George
>
>
>
>
>
> On Tue, 20 Aug 2019 at 11:24, Taylor Fausak <taylor at fausak.me> wrote:
> >
> > It has been a week since I submitted my proposal. During that time, 28
> people voted, with 16 expressing approval and 12 expressing disapproval. To
> everyone that voted so far: Thank you! You made for interesting discussion.
> >
> > I still feel that Haskell would be improved by the addition of a
> `singleton` function to the `Data.List` module. (And also
> `Data.List.NonEmpty`, even though that wasn't part of my original
> proposal.) I would be happy to open a merge request adding code, tests, and
> documentation.
> >
> > I haven't done so yet because I don't know what the next steps are. Can
> someone from the CLC tell me how an official approval or rejection can be
> reached, and how long that might take? Thanks!
> >
> > On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:
> >
> >
> > Andreas, you seem to be mistaken there'd only be one container API? But
> there's several container APIs besides "Data.Set" which provide some
> collection of elements!
> >
> >
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons
> >
> >
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append
> >
> >
> >
> >
> >
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons
> >
> >
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append
> >
> >
> http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons
> >
> >
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons
> >
> >
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append
> >
> > Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <
> andreas.abel at ifi.lmu.de>:
> >
> > Helmut, do you actually know the container APIs?
> >
> > Show me cons and append in Data.Set!
> >
> > On 2019-08-18 19:40, Helmut Schmidt wrote:
> > >
> > >
> > > Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles
> > > <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
> > >
> > >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
> > >     <helmut.schmidt.4711 at gmail.com
> > >     <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
> > >
> > >
> > >         All these philosophical arguments calling for "consistency"
> with
> > >         the container APIs or that function need words for the human
> > >         mind to comprehend seem short-sighted to me. If we were
> > >         consistent about the proposal itself we'd also demand to add
> > >
> > >            cons = (:)
> > >
> > >            empty = []
> > >
> > >            toList = id
> > >
> > >            fromList = id
> > >
> > >
> > >     I honestly have no problem with any of these.
> > >
> > >
> > > I forgot
> > >
> > >      append = (++)
> > >
> > > We also need to address another elephant in the room... those pesky
> > > tuples and their special privileged non-wordy syntax!
> > >
> > >     pair = (,)
> > >
> > >     triple = (,,)
> > >
> > >     quadruple = (,,,)
> > >
> > >     quituple = (,,,,)
> > >
> > >     sextuple = (,,,,,)
> > >
> > >     septuble = (,,,,,,)
> > >
> > >     octuple = (,,,,,,,)
> > >
> > > If Haskell were invented in this century's EU Haskell source code would
> > > be littered with €s instead of $s but then again I wonder why £ wasn't
> > > picked. But I digress. We can kill two birds with one stone here:
> > >
> > >     apply = ($)
> > >
> > >     strictApply = ($!)
> > >
> > >     compose = (.)
> > >
> > >
> > > It's fun to imagine how code using those definitions would like! But
> > > it's still a -1 for me, sorry!
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> _______________________________________________
> 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/20190821/98c41d2d/attachment.html>

From zemyla at gmail.com  Wed Aug 21 18:24:58 2019
From: zemyla at gmail.com (Zemyla)
Date: Wed, 21 Aug 2019 13:24:58 -0500
Subject: Generalize runSTArray and runSTUArray
Message-ID: <CAK7nUjjvU1Ot-TM6yiZ8McM4LssWGWzXP0Sq1L2NAK5pKauvVQ@mail.gmail.com>

The "runSTArray" and "runSTUArray" functions allow efficiently working with
Arrays in the ST monad before turning them immutable; however, they don't
allow any way to return supplemental or alternative information with the
array. There are many times when I've wanted to get an (Array i e, w) or a
Maybe (UArray i e), but I couldn't, and had to use the far-more-inefficient
freezeArray and hope it inlined properly.

What I want are functions that generalize the return types given:

runSTArrayTrav :: Traversable t => (forall s. ST s (t (STArray s i e))) ->
t (Array i e)
runSTArrayTrav m = runST $ m >>= traverse unsafeFreezeSTArray

runSTUArrayTrav :: Traversable t => (forall s. ST s (t (STUArray s i e)))
-> t (UArray i e)
runSTUArrayTrav m = runST $ m >>= traverse unsafeFreezeSTUArray

And then an even more generalized version, which takes a sort of Lens-like
iterator, and allows returning multiple arrays of different kinds, types,
and indices:

runSTArrayWith :: (forall f s. Applicative f => (forall i e. STArray s i e
-> f (Array i e)) -> (forall i e. STUArray s i e -> f (UArray i e)) -> u s
-> f v) -> (forall s. ST s (u s)) -> v
runSTArrayWith tr m = runST $ m >>= tr unsafeFreezeSTArray
unsafeFreezeSTUArray

The advantage of the runSTArrayTrav/runSTUArrayTrav functions, if they're
subsets of the runSTArrayWith function, is that it works with standard
things like (,) and Either, and doesn't require wrapping it in a newtype so
that the s is at the end.

The names of the functions are up for debate, and I know there will be one,
because naming things is one of the two hard problems in computer science,
along with cache invalidation and off-by-one errors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190821/e18ab190/attachment.html>

From david.feuer at gmail.com  Wed Aug 21 18:27:56 2019
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 22 Aug 2019 01:27:56 +0700
Subject: Generalize runSTArray and runSTUArray
In-Reply-To: <CAK7nUjjvU1Ot-TM6yiZ8McM4LssWGWzXP0Sq1L2NAK5pKauvVQ@mail.gmail.com>
References: <CAK7nUjjvU1Ot-TM6yiZ8McM4LssWGWzXP0Sq1L2NAK5pKauvVQ@mail.gmail.com>
Message-ID: <CAMgWh9vZcc56FzGBW_QD_rB-gJYSWQCWpfm7d7Fe37_=Hhqy7g@mail.gmail.com>

I did some work on this sort of thing for primitive, which didn't want it.
But maybe array does. If I don't link to it in the next day, please ping me.

On Thu, Aug 22, 2019, 1:25 AM Zemyla <zemyla at gmail.com> wrote:

> The "runSTArray" and "runSTUArray" functions allow efficiently working
> with Arrays in the ST monad before turning them immutable; however, they
> don't allow any way to return supplemental or alternative information with
> the array. There are many times when I've wanted to get an (Array i e, w)
> or a Maybe (UArray i e), but I couldn't, and had to use the
> far-more-inefficient freezeArray and hope it inlined properly.
>
> What I want are functions that generalize the return types given:
>
> runSTArrayTrav :: Traversable t => (forall s. ST s (t (STArray s i e))) ->
> t (Array i e)
> runSTArrayTrav m = runST $ m >>= traverse unsafeFreezeSTArray
>
> runSTUArrayTrav :: Traversable t => (forall s. ST s (t (STUArray s i e)))
> -> t (UArray i e)
> runSTUArrayTrav m = runST $ m >>= traverse unsafeFreezeSTUArray
>
> And then an even more generalized version, which takes a sort of Lens-like
> iterator, and allows returning multiple arrays of different kinds, types,
> and indices:
>
> runSTArrayWith :: (forall f s. Applicative f => (forall i e. STArray s i e
> -> f (Array i e)) -> (forall i e. STUArray s i e -> f (UArray i e)) -> u s
> -> f v) -> (forall s. ST s (u s)) -> v
> runSTArrayWith tr m = runST $ m >>= tr unsafeFreezeSTArray
> unsafeFreezeSTUArray
>
> The advantage of the runSTArrayTrav/runSTUArrayTrav functions, if they're
> subsets of the runSTArrayWith function, is that it works with standard
> things like (,) and Either, and doesn't require wrapping it in a newtype so
> that the s is at the end.
>
> The names of the functions are up for debate, and I know there will be
> one, because naming things is one of the two hard problems in computer
> science, along with cache invalidation and off-by-one errors.
> _______________________________________________
> 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/20190822/0f144743/attachment.html>

From david.feuer at gmail.com  Wed Aug 21 19:09:55 2019
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 22 Aug 2019 02:09:55 +0700
Subject: Generalize runSTArray and runSTUArray
In-Reply-To: <CAMgWh9vZcc56FzGBW_QD_rB-gJYSWQCWpfm7d7Fe37_=Hhqy7g@mail.gmail.com>
References: <CAK7nUjjvU1Ot-TM6yiZ8McM4LssWGWzXP0Sq1L2NAK5pKauvVQ@mail.gmail.com>
 <CAMgWh9vZcc56FzGBW_QD_rB-gJYSWQCWpfm7d7Fe37_=Hhqy7g@mail.gmail.com>
Message-ID: <CAMgWh9uXhs9dyBunvq0W6EG4G0sdqvsEE2mE4b6hf6bSRmzPBw@mail.gmail.com>

Here's a link to that old PR:

https://github.com/haskell/primitive/pull/109

On Thu, Aug 22, 2019, 1:27 AM David Feuer <david.feuer at gmail.com> wrote:

> I did some work on this sort of thing for primitive, which didn't want it.
> But maybe array does. If I don't link to it in the next day, please ping me.
>
> On Thu, Aug 22, 2019, 1:25 AM Zemyla <zemyla at gmail.com> wrote:
>
>> The "runSTArray" and "runSTUArray" functions allow efficiently working
>> with Arrays in the ST monad before turning them immutable; however, they
>> don't allow any way to return supplemental or alternative information with
>> the array. There are many times when I've wanted to get an (Array i e, w)
>> or a Maybe (UArray i e), but I couldn't, and had to use the
>> far-more-inefficient freezeArray and hope it inlined properly.
>>
>> What I want are functions that generalize the return types given:
>>
>> runSTArrayTrav :: Traversable t => (forall s. ST s (t (STArray s i e)))
>> -> t (Array i e)
>> runSTArrayTrav m = runST $ m >>= traverse unsafeFreezeSTArray
>>
>> runSTUArrayTrav :: Traversable t => (forall s. ST s (t (STUArray s i e)))
>> -> t (UArray i e)
>> runSTUArrayTrav m = runST $ m >>= traverse unsafeFreezeSTUArray
>>
>> And then an even more generalized version, which takes a sort of
>> Lens-like iterator, and allows returning multiple arrays of different
>> kinds, types, and indices:
>>
>> runSTArrayWith :: (forall f s. Applicative f => (forall i e. STArray s i
>> e -> f (Array i e)) -> (forall i e. STUArray s i e -> f (UArray i e)) -> u
>> s -> f v) -> (forall s. ST s (u s)) -> v
>> runSTArrayWith tr m = runST $ m >>= tr unsafeFreezeSTArray
>> unsafeFreezeSTUArray
>>
>> The advantage of the runSTArrayTrav/runSTUArrayTrav functions, if they're
>> subsets of the runSTArrayWith function, is that it works with standard
>> things like (,) and Either, and doesn't require wrapping it in a newtype so
>> that the s is at the end.
>>
>> The names of the functions are up for debate, and I know there will be
>> one, because naming things is one of the two hard problems in computer
>> science, along with cache invalidation and off-by-one errors.
>> _______________________________________________
>> 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/20190822/56b44735/attachment.html>

From zemyla at gmail.com  Wed Aug 21 19:38:31 2019
From: zemyla at gmail.com (Zemyla)
Date: Wed, 21 Aug 2019 14:38:31 -0500
Subject: Generalize runSTArray and runSTUArray
In-Reply-To: <CAMgWh9uXhs9dyBunvq0W6EG4G0sdqvsEE2mE4b6hf6bSRmzPBw@mail.gmail.com>
References: <CAK7nUjjvU1Ot-TM6yiZ8McM4LssWGWzXP0Sq1L2NAK5pKauvVQ@mail.gmail.com>
 <CAMgWh9vZcc56FzGBW_QD_rB-gJYSWQCWpfm7d7Fe37_=Hhqy7g@mail.gmail.com>
 <CAMgWh9uXhs9dyBunvq0W6EG4G0sdqvsEE2mE4b6hf6bSRmzPBw@mail.gmail.com>
Message-ID: <CAK7nUjiiU_+hm0jyCPUY=MKzAhwL4-cMW8hF_8o7YoW0AkEEeQ@mail.gmail.com>

Well, the primary difference between putting it in primitive and putting it
in array is that the primitive library is unsafe, and knows it's unsafe,
and puts its functions like "unsafeFreezeArray" right out there in the
open. Thus, you can write functions like that which traverse over a return
value yourself. The primary reason that "runArray" is in the primitive
library is that it directly unboxes the pointer to the array, passes it out
of the ST monad, and then boxes it up again, so that pattern matches can
see it; you don't get that advantage when you are returning a Traversable
with Arrays inside it.

The array library is supposed to be safe, and Data.Array.ST.Safe exports
only a limited set of functions for working with STArrays. The
"unsafeFreezeSTArray" function isn't even in the public documentation; you
can only learn it exists by looking at the un-Haddocked "Data.Array.Base"
module, which definitely can't be imported by a Safe module.

Meanwhile, the runSTArrayTrav, runSTUArrayTrav, and runSTArrayWith
functions are actually safe, because even though you "know" that the "tr"
function is being run in the ST monad, there's no way to prove it to the
compiler, and thus no way to get your hands on the unsafeFreezeSTArray and
unsafeFreezeSTUArray functions and save them for later.

On the other hand, we might want to change the "Applicative" constraint to
a "Monad" constraint, so that you can turn (for instance) an STArray of
STUArrays into an Array of UArrays:

newtype STArrUArr i e s = STArrUArr (STArray s i (STUArray s i e))

freezeSTArrUArr :: (Ix i, Monad m) => (forall i' e'. STArray s i' e' -> m
(Array i' e')) -> (forall i' e'. STUArray s i' e' -> m (UArray i' e')) ->
STArrUArr i e s -> m (Array i (UArray i e))
freezeSTArrUArr frzA frzUA (STArrUArr ma) = frzA ma >>= traverse frzUA

runArrUArr :: Ix i => (forall s. ST s (STArray s i (STUArray s i e))) ->
Array i (UArray i e)
runArrUArr m = runSTArrayWith freezeSTArrUArr (fmap STArrUArr m)

On Wed, Aug 21, 2019, 14:10 David Feuer <david.feuer at gmail.com> wrote:

> Here's a link to that old PR:
>
> https://github.com/haskell/primitive/pull/109
>
> On Thu, Aug 22, 2019, 1:27 AM David Feuer <david.feuer at gmail.com> wrote:
>
>> I did some work on this sort of thing for primitive, which didn't want
>> it. But maybe array does. If I don't link to it in the next day, please
>> ping me.
>>
>> On Thu, Aug 22, 2019, 1:25 AM Zemyla <zemyla at gmail.com> wrote:
>>
>>> The "runSTArray" and "runSTUArray" functions allow efficiently working
>>> with Arrays in the ST monad before turning them immutable; however, they
>>> don't allow any way to return supplemental or alternative information with
>>> the array. There are many times when I've wanted to get an (Array i e, w)
>>> or a Maybe (UArray i e), but I couldn't, and had to use the
>>> far-more-inefficient freezeArray and hope it inlined properly.
>>>
>>> What I want are functions that generalize the return types given:
>>>
>>> runSTArrayTrav :: Traversable t => (forall s. ST s (t (STArray s i e)))
>>> -> t (Array i e)
>>> runSTArrayTrav m = runST $ m >>= traverse unsafeFreezeSTArray
>>>
>>> runSTUArrayTrav :: Traversable t => (forall s. ST s (t (STUArray s i
>>> e))) -> t (UArray i e)
>>> runSTUArrayTrav m = runST $ m >>= traverse unsafeFreezeSTUArray
>>>
>>> And then an even more generalized version, which takes a sort of
>>> Lens-like iterator, and allows returning multiple arrays of different
>>> kinds, types, and indices:
>>>
>>> runSTArrayWith :: (forall f s. Applicative f => (forall i e. STArray s i
>>> e -> f (Array i e)) -> (forall i e. STUArray s i e -> f (UArray i e)) -> u
>>> s -> f v) -> (forall s. ST s (u s)) -> v
>>> runSTArrayWith tr m = runST $ m >>= tr unsafeFreezeSTArray
>>> unsafeFreezeSTUArray
>>>
>>> The advantage of the runSTArrayTrav/runSTUArrayTrav functions, if
>>> they're subsets of the runSTArrayWith function, is that it works with
>>> standard things like (,) and Either, and doesn't require wrapping it in a
>>> newtype so that the s is at the end.
>>>
>>> The names of the functions are up for debate, and I know there will be
>>> one, because naming things is one of the two hard problems in computer
>>> science, along with cache invalidation and off-by-one errors.
>>> _______________________________________________
>>> 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/20190821/bc87803a/attachment.html>

From lemming at henning-thielemann.de  Thu Aug 22 04:45:56 2019
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 22 Aug 2019 06:45:56 +0200 (CEST)
Subject: Generalize runSTArray and runSTUArray
In-Reply-To: <CAK7nUjjvU1Ot-TM6yiZ8McM4LssWGWzXP0Sq1L2NAK5pKauvVQ@mail.gmail.com>
References: <CAK7nUjjvU1Ot-TM6yiZ8McM4LssWGWzXP0Sq1L2NAK5pKauvVQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1908220631430.6568@sputnik>


On Wed, 21 Aug 2019, Zemyla wrote:

> The "runSTArray" and "runSTUArray" functions allow efficiently working 
> with Arrays in the ST monad before turning them immutable

I think instead of some new functions we should have a Kleisli Arrow data 
type that hides unsafeFreeze for us.

newtype Freezer s a b =
    -- private constructor and accessor
    Freezer {getFreezer :: a -> ST s b}

instance Category Freezer where
instance Arrow Freezer where

quickFreeze :: Freezer s (STArray s i e) (Array i e)
quickFreeze = Freezer unsafeFreeze

runFrozen :: (forall s. Freezer s a b) -> (forall s. ST s a) -> b
runFrozen freezer st = runST (getFreezer (freezer st))


For moving two arrays and an additional value out, you would do

runFrozen ((quickFreeze *** quickFreeze) *** id) st

From svenpanne at gmail.com  Thu Aug 22 09:58:21 2019
From: svenpanne at gmail.com (Sven Panne)
Date: Thu, 22 Aug 2019 11:58:21 +0200
Subject: Fwd: Proposal: Add singleton function to Data.List module
In-Reply-To: <CANBN=mtwprCF_MdX6EQkQzP75Y0hyBtPJtEZW6yZbhi9Cufxog@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
 <CANBN=mtwprCF_MdX6EQkQzP75Y0hyBtPJtEZW6yZbhi9Cufxog@mail.gmail.com>
Message-ID: <CANBN=muOJbKMutsQPKuF2JxTTLQQ70DoV5+0ZOyfSx9CumqoBQ@mail.gmail.com>

Am Mi., 21. Aug. 2019 um 12:22 Uhr schrieb Nathan Bouscal <
nbouscal at gmail.com>:

> I would strongly encourage anyone inclined to say things like “there's no benefit
> in having the function” to consider reframing the sentiment as “I wouldn’t
> benefit from having the function, and don’t understand the benefit others
> will gain.” Once you’ve done that reframe, you can notice that there’s a
> lack of understanding toward which the appropriate emotional stance is
> curiosity, not dismissiveness. A lot of people have clearly expressed in
> this thread that they would benefit from this function, and when you assert
> as fact that such benefit does not exist, you’re implicitly dismissing and
> devaluing their experience. [...]
>

There is also another side of the coin: A lot of people have clearly
expressed counterarguments,  so *their* experience has been equally
"dismissed" or "devalued". Reframing the discussion shouldn't be biased,
otherwise it's just a cheap trick to make one side of the discussion more
valuable/stronger. Furthermore, a technical discussion doesn't need to be
an excercise in nonviolent communication, as long as people don't start
insulting each other.

I think the main problem of this discussion (and other similar threads on
this list) is that there is no consensus about how to design an API. IMHO,
piling up little helpers just because they came up in a few places is a
recipe for horrible, bloated APIs. The questions one should ask are "Does
it generalize things?", "Does it make my API more powerful?" (i.e. can I do
things I couldn't do before), "Does it remove common pitfalls?" etc.  But
this is just my personal view, obviously others seem to disagree.... :-/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190822/4ee8f78e/attachment.html>

From malcolm.wallace at me.com  Thu Aug 22 11:11:49 2019
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Thu, 22 Aug 2019 12:11:49 +0100
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
Message-ID: <9937EA55-D1DD-41AF-A1D9-A9EF2693557A@me.com>

I have some data to contribute, from our proprietary codebase of some 4MLoC.  We are perhaps unusual in having the singleton function on lists already for 10 years, so it is easy to do a comparison of the frequency of use.

The robot monkey (:[]) has 378 uses.
Monkey with a space (: []) has 36 uses.
The list singleton function has 18 uses.

We also have many other singleton functions at more than 20 different types (vector, tuple, map, set, interval, relation, dict, expression, etc), totalling 1893 uses, so the concept/vocabulary is pretty well-known.

In addition, I counted the number of direct constructions of lists that use :[] unparenthesised, i.e like x:y:[], and there are 489.

I find it interesting that given the choice of “singleton” vs direct construction or a partially applied operator, our devs seem to prefer the brevity and naturality of the colon.

Regards,
    Malcolm

> On 21 Aug 2019, at 06:31, George Wilson <george at wils.online> wrote:
> 
> Hi Taylor,
> 
> I'm on the Core Libraries Committee. Thank you for your proposal.
> Regarding the +-1 messages in this thread, they are useful to gauge
> community opinion, but they are not votes because the libraries
> process is not determined by a vote.
> 
> Despite seeming innocuous, the proposed change requires careful
> consideration: Data.List is specified by the Haskell Report, so adding
> this function would affect the report.
> While simple changes to base are typically handled directly by one of
> base's maintainers, this change is report-affecting, so it is
> "controversial" (as defined in [1]). Hence the CLC is discussing the
> proposed change amongst ourselves before a maintainer makes their
> decision.
> 
> [1] https://wiki.haskell.org/Library_submissions
> 
> Cheers,
> George
> 
> 
> 
> 
> 
>> On Tue, 20 Aug 2019 at 11:24, Taylor Fausak <taylor at fausak.me> wrote:
>> 
>> It has been a week since I submitted my proposal. During that time, 28 people voted, with 16 expressing approval and 12 expressing disapproval. To everyone that voted so far: Thank you! You made for interesting discussion.
>> 
>> I still feel that Haskell would be improved by the addition of a `singleton` function to the `Data.List` module. (And also `Data.List.NonEmpty`, even though that wasn't part of my original proposal.) I would be happy to open a merge request adding code, tests, and documentation.
>> 
>> I haven't done so yet because I don't know what the next steps are. Can someone from the CLC tell me how an official approval or rejection can be reached, and how long that might take? Thanks!
>> 
>> On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:
>> 
>> 
>> Andreas, you seem to be mistaken there'd only be one container API? But there's several container APIs besides "Data.Set" which provide some collection of elements!
>> 
>> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons
>> 
>> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append
>> 
>> 
>> 
>> 
>> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons
>> 
>> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append
>> 
>> http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons
>> 
>> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons
>> 
>> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append
>> 
>> Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <andreas.abel at ifi.lmu.de>:
>> 
>> Helmut, do you actually know the container APIs?
>> 
>> Show me cons and append in Data.Set!
>> 
>>> On 2019-08-18 19:40, Helmut Schmidt wrote:
>>> 
>>> 
>>> Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles
>>> <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
>>> 
>>>    On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>>>    <helmut.schmidt.4711 at gmail.com
>>>    <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
>>> 
>>> 
>>>        All these philosophical arguments calling for "consistency" with
>>>        the container APIs or that function need words for the human
>>>        mind to comprehend seem short-sighted to me. If we were
>>>        consistent about the proposal itself we'd also demand to add
>>> 
>>>           cons = (:)
>>> 
>>>           empty = []
>>> 
>>>           toList = id
>>> 
>>>           fromList = id
>>> 
>>> 
>>>    I honestly have no problem with any of these.
>>> 
>>> 
>>> I forgot
>>> 
>>>     append = (++)
>>> 
>>> We also need to address another elephant in the room... those pesky
>>> tuples and their special privileged non-wordy syntax!
>>> 
>>>    pair = (,)
>>> 
>>>    triple = (,,)
>>> 
>>>    quadruple = (,,,)
>>> 
>>>    quituple = (,,,,)
>>> 
>>>    sextuple = (,,,,,)
>>> 
>>>    septuble = (,,,,,,)
>>> 
>>>    octuple = (,,,,,,,)
>>> 
>>> If Haskell were invented in this century's EU Haskell source code would
>>> be littered with €s instead of $s but then again I wonder why £ wasn't
>>> picked. But I digress. We can kill two birds with one stone here:
>>> 
>>>    apply = ($)
>>> 
>>>    strictApply = ($!)
>>> 
>>>    compose = (.)
>>> 
>>> 
>>> It's fun to imagine how code using those definitions would like! But
>>> it's still a -1 for me, sorry!
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


From eacameron at gmail.com  Thu Aug 22 12:11:21 2019
From: eacameron at gmail.com (Elliot Cameron)
Date: Thu, 22 Aug 2019 08:11:21 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <9937EA55-D1DD-41AF-A1D9-A9EF2693557A@me.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <9937EA55-D1DD-41AF-A1D9-A9EF2693557A@me.com>
Message-ID: <CANPxu=zZrkuhQiAzKyCKSzZ+cbQ82yuts1-9S2f2Ls4QCPxw_Q@mail.gmail.com>

We also use the money face regularly in our code bases, but I think it's
only because the singleton function for lists is not already defined. Every
time I see/use it I wince a little.

Some devs I know will go to lengths to avoid an extra import line. So you
often see 'maybe x id' instead of 'fromMaybe x' and 'flip traverse' instead
of 'for'.

No other containers are in Prelude and must have their APIs imported
qualified. So they don't suffer from this bias against imports.

In any code base the defines it's own idioms, like singleton on lists, you
have to imagine that what's obviously on Hackage and what is proprietary
will not get the same level of commitment.

P.S. Based on arguments against non-fundanental combinators, I suppose we
should remove 'fromMaybe' and 'for' since they are not fundamental?

This debate is definitely more ideological than I think anyone quite
realized at first. At the very least, having the CLC's position clearly
documented might help in the future.

On Thu, Aug 22, 2019, 7:12 AM Malcolm Wallace via Libraries <
libraries at haskell.org> wrote:

> I have some data to contribute, from our proprietary codebase of some
> 4MLoC.  We are perhaps unusual in having the singleton function on lists
> already for 10 years, so it is easy to do a comparison of the frequency of
> use.
>
> The robot monkey (:[]) has 378 uses.
> Monkey with a space (: []) has 36 uses.
> The list singleton function has 18 uses.
>
> We also have many other singleton functions at more than 20 different
> types (vector, tuple, map, set, interval, relation, dict, expression, etc),
> totalling 1893 uses, so the concept/vocabulary is pretty well-known.
>
> In addition, I counted the number of direct constructions of lists that
> use :[] unparenthesised, i.e like x:y:[], and there are 489.
>
> I find it interesting that given the choice of “singleton” vs direct
> construction or a partially applied operator, our devs seem to prefer the
> brevity and naturality of the colon.
>
> Regards,
>     Malcolm
>
> > On 21 Aug 2019, at 06:31, George Wilson <george at wils.online> wrote:
> >
> > Hi Taylor,
> >
> > I'm on the Core Libraries Committee. Thank you for your proposal.
> > Regarding the +-1 messages in this thread, they are useful to gauge
> > community opinion, but they are not votes because the libraries
> > process is not determined by a vote.
> >
> > Despite seeming innocuous, the proposed change requires careful
> > consideration: Data.List is specified by the Haskell Report, so adding
> > this function would affect the report.
> > While simple changes to base are typically handled directly by one of
> > base's maintainers, this change is report-affecting, so it is
> > "controversial" (as defined in [1]). Hence the CLC is discussing the
> > proposed change amongst ourselves before a maintainer makes their
> > decision.
> >
> > [1] https://wiki.haskell.org/Library_submissions
> >
> > Cheers,
> > George
> >
> >
> >
> >
> >
> >> On Tue, 20 Aug 2019 at 11:24, Taylor Fausak <taylor at fausak.me> wrote:
> >>
> >> It has been a week since I submitted my proposal. During that time, 28
> people voted, with 16 expressing approval and 12 expressing disapproval. To
> everyone that voted so far: Thank you! You made for interesting discussion.
> >>
> >> I still feel that Haskell would be improved by the addition of a
> `singleton` function to the `Data.List` module. (And also
> `Data.List.NonEmpty`, even though that wasn't part of my original
> proposal.) I would be happy to open a merge request adding code, tests, and
> documentation.
> >>
> >> I haven't done so yet because I don't know what the next steps are. Can
> someone from the CLC tell me how an official approval or rejection can be
> reached, and how long that might take? Thanks!
> >>
> >> On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:
> >>
> >>
> >> Andreas, you seem to be mistaken there'd only be one container API? But
> there's several container APIs besides "Data.Set" which provide some
> collection of elements!
> >>
> >>
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons
> >>
> >>
> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append
> >>
> >>
> >>
> >>
> >>
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons
> >>
> >>
> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append
> >>
> >>
> http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons
> >>
> >>
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons
> >>
> >>
> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append
> >>
> >> Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <
> andreas.abel at ifi.lmu.de>:
> >>
> >> Helmut, do you actually know the container APIs?
> >>
> >> Show me cons and append in Data.Set!
> >>
> >>> On 2019-08-18 19:40, Helmut Schmidt wrote:
> >>>
> >>>
> >>> Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles
> >>> <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
> >>>
> >>>    On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
> >>>    <helmut.schmidt.4711 at gmail.com
> >>>    <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
> >>>
> >>>
> >>>        All these philosophical arguments calling for "consistency" with
> >>>        the container APIs or that function need words for the human
> >>>        mind to comprehend seem short-sighted to me. If we were
> >>>        consistent about the proposal itself we'd also demand to add
> >>>
> >>>           cons = (:)
> >>>
> >>>           empty = []
> >>>
> >>>           toList = id
> >>>
> >>>           fromList = id
> >>>
> >>>
> >>>    I honestly have no problem with any of these.
> >>>
> >>>
> >>> I forgot
> >>>
> >>>     append = (++)
> >>>
> >>> We also need to address another elephant in the room... those pesky
> >>> tuples and their special privileged non-wordy syntax!
> >>>
> >>>    pair = (,)
> >>>
> >>>    triple = (,,)
> >>>
> >>>    quadruple = (,,,)
> >>>
> >>>    quituple = (,,,,)
> >>>
> >>>    sextuple = (,,,,,)
> >>>
> >>>    septuble = (,,,,,,)
> >>>
> >>>    octuple = (,,,,,,,)
> >>>
> >>> If Haskell were invented in this century's EU Haskell source code would
> >>> be littered with €s instead of $s but then again I wonder why £ wasn't
> >>> picked. But I digress. We can kill two birds with one stone here:
> >>>
> >>>    apply = ($)
> >>>
> >>>    strictApply = ($!)
> >>>
> >>>    compose = (.)
> >>>
> >>>
> >>> It's fun to imagine how code using those definitions would like! But
> >>> it's still a -1 for me, sorry!
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> > _______________________________________________
> > 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/20190822/c4d40951/attachment-0001.html>

From eacameron at gmail.com  Thu Aug 22 15:19:55 2019
From: eacameron at gmail.com (Elliot Cameron)
Date: Thu, 22 Aug 2019 11:19:55 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CANPxu=zZrkuhQiAzKyCKSzZ+cbQ82yuts1-9S2f2Ls4QCPxw_Q@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <9937EA55-D1DD-41AF-A1D9-A9EF2693557A@me.com>
 <CANPxu=zZrkuhQiAzKyCKSzZ+cbQ82yuts1-9S2f2Ls4QCPxw_Q@mail.gmail.com>
Message-ID: <CANPxu=z1oGDyxiNo0NfMo=5ojs5fETbS=icv2u6t97nvp0CJxg@mail.gmail.com>

Hilariously, I just saw this article on my feed which sheepishly admits
that it's example of "singleton" isn't actually a thing in Data.List:
https://typeclasses.com/featured/singleton

On Thu, Aug 22, 2019 at 8:11 AM Elliot Cameron <eacameron at gmail.com> wrote:

> We also use the money face regularly in our code bases, but I think it's
> only because the singleton function for lists is not already defined. Every
> time I see/use it I wince a little.
>
> Some devs I know will go to lengths to avoid an extra import line. So you
> often see 'maybe x id' instead of 'fromMaybe x' and 'flip traverse' instead
> of 'for'.
>
> No other containers are in Prelude and must have their APIs imported
> qualified. So they don't suffer from this bias against imports.
>
> In any code base the defines it's own idioms, like singleton on lists, you
> have to imagine that what's obviously on Hackage and what is proprietary
> will not get the same level of commitment.
>
> P.S. Based on arguments against non-fundanental combinators, I suppose we
> should remove 'fromMaybe' and 'for' since they are not fundamental?
>
> This debate is definitely more ideological than I think anyone quite
> realized at first. At the very least, having the CLC's position clearly
> documented might help in the future.
>
> On Thu, Aug 22, 2019, 7:12 AM Malcolm Wallace via Libraries <
> libraries at haskell.org> wrote:
>
>> I have some data to contribute, from our proprietary codebase of some
>> 4MLoC.  We are perhaps unusual in having the singleton function on lists
>> already for 10 years, so it is easy to do a comparison of the frequency of
>> use.
>>
>> The robot monkey (:[]) has 378 uses.
>> Monkey with a space (: []) has 36 uses.
>> The list singleton function has 18 uses.
>>
>> We also have many other singleton functions at more than 20 different
>> types (vector, tuple, map, set, interval, relation, dict, expression, etc),
>> totalling 1893 uses, so the concept/vocabulary is pretty well-known.
>>
>> In addition, I counted the number of direct constructions of lists that
>> use :[] unparenthesised, i.e like x:y:[], and there are 489.
>>
>> I find it interesting that given the choice of “singleton” vs direct
>> construction or a partially applied operator, our devs seem to prefer the
>> brevity and naturality of the colon.
>>
>> Regards,
>>     Malcolm
>>
>> > On 21 Aug 2019, at 06:31, George Wilson <george at wils.online> wrote:
>> >
>> > Hi Taylor,
>> >
>> > I'm on the Core Libraries Committee. Thank you for your proposal.
>> > Regarding the +-1 messages in this thread, they are useful to gauge
>> > community opinion, but they are not votes because the libraries
>> > process is not determined by a vote.
>> >
>> > Despite seeming innocuous, the proposed change requires careful
>> > consideration: Data.List is specified by the Haskell Report, so adding
>> > this function would affect the report.
>> > While simple changes to base are typically handled directly by one of
>> > base's maintainers, this change is report-affecting, so it is
>> > "controversial" (as defined in [1]). Hence the CLC is discussing the
>> > proposed change amongst ourselves before a maintainer makes their
>> > decision.
>> >
>> > [1] https://wiki.haskell.org/Library_submissions
>> >
>> > Cheers,
>> > George
>> >
>> >
>> >
>> >
>> >
>> >> On Tue, 20 Aug 2019 at 11:24, Taylor Fausak <taylor at fausak.me> wrote:
>> >>
>> >> It has been a week since I submitted my proposal. During that time, 28
>> people voted, with 16 expressing approval and 12 expressing disapproval. To
>> everyone that voted so far: Thank you! You made for interesting discussion.
>> >>
>> >> I still feel that Haskell would be improved by the addition of a
>> `singleton` function to the `Data.List` module. (And also
>> `Data.List.NonEmpty`, even though that wasn't part of my original
>> proposal.) I would be happy to open a merge request adding code, tests, and
>> documentation.
>> >>
>> >> I haven't done so yet because I don't know what the next steps are.
>> Can someone from the CLC tell me how an official approval or rejection can
>> be reached, and how long that might take? Thanks!
>> >>
>> >> On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:
>> >>
>> >>
>> >> Andreas, you seem to be mistaken there'd only be one container API?
>> But there's several container APIs besides "Data.Set" which provide some
>> collection of elements!
>> >>
>> >>
>> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons
>> >>
>> >>
>> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append
>> >>
>> >>
>> >>
>> >>
>> >>
>> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons
>> >>
>> >>
>> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append
>> >>
>> >>
>> http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons
>> >>
>> >>
>> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons
>> >>
>> >>
>> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append
>> >>
>> >> Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <
>> andreas.abel at ifi.lmu.de>:
>> >>
>> >> Helmut, do you actually know the container APIs?
>> >>
>> >> Show me cons and append in Data.Set!
>> >>
>> >>> On 2019-08-18 19:40, Helmut Schmidt wrote:
>> >>>
>> >>>
>> >>> Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles
>> >>> <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
>> >>>
>> >>>    On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>> >>>    <helmut.schmidt.4711 at gmail.com
>> >>>    <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
>> >>>
>> >>>
>> >>>        All these philosophical arguments calling for "consistency"
>> with
>> >>>        the container APIs or that function need words for the human
>> >>>        mind to comprehend seem short-sighted to me. If we were
>> >>>        consistent about the proposal itself we'd also demand to add
>> >>>
>> >>>           cons = (:)
>> >>>
>> >>>           empty = []
>> >>>
>> >>>           toList = id
>> >>>
>> >>>           fromList = id
>> >>>
>> >>>
>> >>>    I honestly have no problem with any of these.
>> >>>
>> >>>
>> >>> I forgot
>> >>>
>> >>>     append = (++)
>> >>>
>> >>> We also need to address another elephant in the room... those pesky
>> >>> tuples and their special privileged non-wordy syntax!
>> >>>
>> >>>    pair = (,)
>> >>>
>> >>>    triple = (,,)
>> >>>
>> >>>    quadruple = (,,,)
>> >>>
>> >>>    quituple = (,,,,)
>> >>>
>> >>>    sextuple = (,,,,,)
>> >>>
>> >>>    septuble = (,,,,,,)
>> >>>
>> >>>    octuple = (,,,,,,,)
>> >>>
>> >>> If Haskell were invented in this century's EU Haskell source code
>> would
>> >>> be littered with €s instead of $s but then again I wonder why £ wasn't
>> >>> picked. But I digress. We can kill two birds with one stone here:
>> >>>
>> >>>    apply = ($)
>> >>>
>> >>>    strictApply = ($!)
>> >>>
>> >>>    compose = (.)
>> >>>
>> >>>
>> >>> It's fun to imagine how code using those definitions would like! But
>> >>> it's still a -1 for me, sorry!
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> > _______________________________________________
>> > 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/20190822/529ffc82/attachment.html>

From kris.nuttycombe at gmail.com  Thu Aug 22 17:11:14 2019
From: kris.nuttycombe at gmail.com (Kris Nuttycombe)
Date: Thu, 22 Aug 2019 11:11:14 -0600
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CANBN=muOJbKMutsQPKuF2JxTTLQQ70DoV5+0ZOyfSx9CumqoBQ@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
 <CANBN=mtwprCF_MdX6EQkQzP75Y0hyBtPJtEZW6yZbhi9Cufxog@mail.gmail.com>
 <CANBN=muOJbKMutsQPKuF2JxTTLQQ70DoV5+0ZOyfSx9CumqoBQ@mail.gmail.com>
Message-ID: <CAHFpbukqHTc-NDJ6waF_SEGDUyiZX0DpS0b8tzXd_31hweTUFg@mail.gmail.com>

On Thu, Aug 22, 2019 at 3:58 AM Sven Panne <svenpanne at gmail.com> wrote:

> I think the main problem of this discussion (and other similar threads on
> this list) is that there is no consensus about how to design an API. IMHO,
> piling up little helpers just because they came up in a few places is a
> recipe for horrible, bloated APIs. The questions one should ask are "Does
> it generalize things?", "Does it make my API more powerful?" (i.e. can I do
> things I couldn't do before), "Does it remove common pitfalls?" etc.  But
> this is just my personal view, obviously others seem to disagree.... :-/
>

 I think there's a significant difference between "little helper" and "the
monomorphic function that is used to implement `pure`" - with a slightly
different framing, we might be able to come to an agreement that both the
monomorphic an polymorphic versions of this function are useful in
different contexts.

https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.Base.html#line-972

We define a monomorphic function for this operation, we just hide it in the
implementation of the typeclass instance; we do this frequently,
intentionally making a monomorphic function inaccessible to the user unless
it's called in a polymorphic context (and, if they want to intentionally
monomorphise it, require using an extension - type applications - which is
particularly ugly/inconvenient for operators like `>>=`.) I think this is
unfortunate as a general design choice; the user of a library should have
the flexibility to choose, not be forced into one or the other. For [] we
have the robot monkey operator, and this is an idiom that people can become
familiar with - but it does not appear natively in any documentation; it is
a partially applied constructor rather than a top-level function.

My guiding principle for API design is that one should always expose the
fundamental building blocks as a low-level API, and then provide a smaller
interface for the common use cases. Typeclass instances are no different -
they are the general interface that allows us to invoke what is ultimately
a monomorphic, low-level building block function in a polymorphic context.

Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190822/4e664f8a/attachment.html>

From gereeter+haskell.libraries at gmail.com  Thu Aug 22 20:09:33 2019
From: gereeter+haskell.libraries at gmail.com (Jonathan S)
Date: Thu, 22 Aug 2019 15:09:33 -0500
Subject: Generalize runSTArray and runSTUArray
In-Reply-To: <alpine.DEB.2.20.1908220631430.6568@sputnik>
References: <CAK7nUjjvU1Ot-TM6yiZ8McM4LssWGWzXP0Sq1L2NAK5pKauvVQ@mail.gmail.com>
 <alpine.DEB.2.20.1908220631430.6568@sputnik>
Message-ID: <CALKmN4_5JuqrJmcEr_EieMoSeg-C_BbobXuvdOkyedki8csOQg@mail.gmail.com>

Even simpler, Freezer could just be a Monad denoting arbitrary "cleanup"
actions, as long as they don't involve writes.


-- | A computation that is guaranteed to run after all modifications are
complete.
newtype Freeze s a = {- private constructor and accessor -} Freeze {
getFreeze :: ST s a } deriving (Functor, Applicative, Monad)

freezeArray :: (Ix i, MArray a e (ST s), IArray b e) => a i e -> Freeze s
(b i e)
freezeArray arr = Freeze (unsafeFreeze arr)

-- Reads are fine too, just not writes
freezeRef :: STRef s a -> Freeze s a
freezeRef ref = Freeze (readSTRef ref)

runSTFreeze :: (forall s . ST s (Freeze s a)) -> a
runSTFreeze act = runST (act >>= getFreeze)



The proposed -Trav and -With functions can be implemented straightforwardly
from that if desired:
runSTArrayTrav m = runSTFreeze (m >>= traverse freezeArray)
runSTUArrayTrav m = runSTFreeze (m >>= traverse freezeArray)
runSTArrayWith tr m = runSTFreeze (m >>= tr freezeArray freezeArray)


On Wed, Aug 21, 2019 at 11:46 PM Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Wed, 21 Aug 2019, Zemyla wrote:
>
> > The "runSTArray" and "runSTUArray" functions allow efficiently working
> > with Arrays in the ST monad before turning them immutable
>
> I think instead of some new functions we should have a Kleisli Arrow data
> type that hides unsafeFreeze for us.
>
> newtype Freezer s a b =
>     -- private constructor and accessor
>     Freezer {getFreezer :: a -> ST s b}
>
> instance Category Freezer where
> instance Arrow Freezer where
>
> quickFreeze :: Freezer s (STArray s i e) (Array i e)
> quickFreeze = Freezer unsafeFreeze
>
> runFrozen :: (forall s. Freezer s a b) -> (forall s. ST s a) -> b
> runFrozen freezer st = runST (getFreezer (freezer st))
>
>
> For moving two arrays and an additional value out, you would do
>
> runFrozen ((quickFreeze *** quickFreeze) *** id) st
> _______________________________________________
> 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/20190822/8796e285/attachment.html>

From tmorris at tmorris.net  Thu Aug 22 22:51:42 2019
From: tmorris at tmorris.net (Tony Morris)
Date: Fri, 23 Aug 2019 08:51:42 +1000
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAHFpbukqHTc-NDJ6waF_SEGDUyiZX0DpS0b8tzXd_31hweTUFg@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
 <CANBN=mtwprCF_MdX6EQkQzP75Y0hyBtPJtEZW6yZbhi9Cufxog@mail.gmail.com>
 <CANBN=muOJbKMutsQPKuF2JxTTLQQ70DoV5+0ZOyfSx9CumqoBQ@mail.gmail.com>
 <CAHFpbukqHTc-NDJ6waF_SEGDUyiZX0DpS0b8tzXd_31hweTUFg@mail.gmail.com>
Message-ID: <CAJf6UshQ=-ktRwB1m7VyPj2Y5OrSaz81vJ+W3ufBHXjgqjr-kw@mail.gmail.com>

In (my) most to least preferred:

* NonEmpty#singleton
* <doesn't exist at all>
* []#singleton


On Fri, Aug 23, 2019 at 3:12 AM Kris Nuttycombe <kris.nuttycombe at gmail.com>
wrote:

> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne <svenpanne at gmail.com> wrote:
>
>> I think the main problem of this discussion (and other similar threads on
>> this list) is that there is no consensus about how to design an API. IMHO,
>> piling up little helpers just because they came up in a few places is a
>> recipe for horrible, bloated APIs. The questions one should ask are "Does
>> it generalize things?", "Does it make my API more powerful?" (i.e. can I do
>> things I couldn't do before), "Does it remove common pitfalls?" etc.  But
>> this is just my personal view, obviously others seem to disagree.... :-/
>>
>
>  I think there's a significant difference between "little helper" and "the
> monomorphic function that is used to implement `pure`" - with a slightly
> different framing, we might be able to come to an agreement that both the
> monomorphic an polymorphic versions of this function are useful in
> different contexts.
>
>
> https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.Base.html#line-972
>
> We define a monomorphic function for this operation, we just hide it in
> the implementation of the typeclass instance; we do this frequently,
> intentionally making a monomorphic function inaccessible to the user unless
> it's called in a polymorphic context (and, if they want to intentionally
> monomorphise it, require using an extension - type applications - which is
> particularly ugly/inconvenient for operators like `>>=`.) I think this is
> unfortunate as a general design choice; the user of a library should have
> the flexibility to choose, not be forced into one or the other. For [] we
> have the robot monkey operator, and this is an idiom that people can become
> familiar with - but it does not appear natively in any documentation; it is
> a partially applied constructor rather than a top-level function.
>
> My guiding principle for API design is that one should always expose the
> fundamental building blocks as a low-level API, and then provide a smaller
> interface for the common use cases. Typeclass instances are no different -
> they are the general interface that allows us to invoke what is ultimately
> a monomorphic, low-level building block function in a polymorphic context.
>
> Kris
> _______________________________________________
> 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/20190823/6e9a1267/attachment.html>

From zemyla at gmail.com  Thu Aug 22 23:20:49 2019
From: zemyla at gmail.com (Zemyla)
Date: Thu, 22 Aug 2019 18:20:49 -0500
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAJf6UshQ=-ktRwB1m7VyPj2Y5OrSaz81vJ+W3ufBHXjgqjr-kw@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
 <CANBN=mtwprCF_MdX6EQkQzP75Y0hyBtPJtEZW6yZbhi9Cufxog@mail.gmail.com>
 <CANBN=muOJbKMutsQPKuF2JxTTLQQ70DoV5+0ZOyfSx9CumqoBQ@mail.gmail.com>
 <CAHFpbukqHTc-NDJ6waF_SEGDUyiZX0DpS0b8tzXd_31hweTUFg@mail.gmail.com>
 <CAJf6UshQ=-ktRwB1m7VyPj2Y5OrSaz81vJ+W3ufBHXjgqjr-kw@mail.gmail.com>
Message-ID: <CAK7nUjgSUUaUYNB-e2Gi=Byj2wim4bqEhRbB0rJQuJaLaAcWow@mail.gmail.com>

Why hasn't anyone noticed that the singleton function for NonEmpty is just
a monkey robot with a mustache? (:|[])

Also, pure works perfectly fine here as well.

On Thu, Aug 22, 2019, 17:52 Tony Morris <tmorris at tmorris.net> wrote:

> In (my) most to least preferred:
>
> * NonEmpty#singleton
> * <doesn't exist at all>
> * []#singleton
>
>
> On Fri, Aug 23, 2019 at 3:12 AM Kris Nuttycombe <kris.nuttycombe at gmail.com>
> wrote:
>
>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne <svenpanne at gmail.com> wrote:
>>
>>> I think the main problem of this discussion (and other similar threads
>>> on this list) is that there is no consensus about how to design an API.
>>> IMHO, piling up little helpers just because they came up in a few places is
>>> a recipe for horrible, bloated APIs. The questions one should ask are "Does
>>> it generalize things?", "Does it make my API more powerful?" (i.e. can I do
>>> things I couldn't do before), "Does it remove common pitfalls?" etc.  But
>>> this is just my personal view, obviously others seem to disagree.... :-/
>>>
>>
>>  I think there's a significant difference between "little helper" and
>> "the monomorphic function that is used to implement `pure`" - with a
>> slightly different framing, we might be able to come to an agreement that
>> both the monomorphic an polymorphic versions of this function are useful in
>> different contexts.
>>
>>
>> https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.Base.html#line-972
>>
>> We define a monomorphic function for this operation, we just hide it in
>> the implementation of the typeclass instance; we do this frequently,
>> intentionally making a monomorphic function inaccessible to the user unless
>> it's called in a polymorphic context (and, if they want to intentionally
>> monomorphise it, require using an extension - type applications - which is
>> particularly ugly/inconvenient for operators like `>>=`.) I think this is
>> unfortunate as a general design choice; the user of a library should have
>> the flexibility to choose, not be forced into one or the other. For [] we
>> have the robot monkey operator, and this is an idiom that people can become
>> familiar with - but it does not appear natively in any documentation; it is
>> a partially applied constructor rather than a top-level function.
>>
>> My guiding principle for API design is that one should always expose the
>> fundamental building blocks as a low-level API, and then provide a smaller
>> interface for the common use cases. Typeclass instances are no different -
>> they are the general interface that allows us to invoke what is ultimately
>> a monomorphic, low-level building block function in a polymorphic context.
>>
>> Kris
>> _______________________________________________
>> 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/20190822/9307e49e/attachment.html>

From svenpanne at gmail.com  Fri Aug 23 07:56:41 2019
From: svenpanne at gmail.com (Sven Panne)
Date: Fri, 23 Aug 2019 09:56:41 +0200
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CAHFpbukqHTc-NDJ6waF_SEGDUyiZX0DpS0b8tzXd_31hweTUFg@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
 <CANBN=mtwprCF_MdX6EQkQzP75Y0hyBtPJtEZW6yZbhi9Cufxog@mail.gmail.com>
 <CANBN=muOJbKMutsQPKuF2JxTTLQQ70DoV5+0ZOyfSx9CumqoBQ@mail.gmail.com>
 <CAHFpbukqHTc-NDJ6waF_SEGDUyiZX0DpS0b8tzXd_31hweTUFg@mail.gmail.com>
Message-ID: <CANBN=mtF+wNJZTRWzS9O2b5ZXAe=PTo3rHf2+CFM00Wy2hSxGw@mail.gmail.com>

Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe <
kris.nuttycombe at gmail.com>:

> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne <svenpanne at gmail.com> wrote:
>
>>  I think there's a significant difference between "little helper" and
>> "the monomorphic function that is used to implement `pure`" - with a
>> slightly different framing, we might be able to come to an agreement that
>> both the monomorphic an polymorphic versions of this function are useful in
>> different contexts. [...]
>>
>
I think we can agree that we disagree here. ;-) My brain is too small to
remember the names of myriads of trivial helpers, so I very much prefer
general, orthogonal things. In our case: If we have a general, polymorphic
function (often from a type class), just use that. If for some reason
(rarely!) I want a more monomorphic function, I can just add a plain old
type signature somewhere (no need for funky language extensions like type
applications). This radically reduces the number of things one has to
remember. In our case: Know type classes + know a way to make things more
monomorphic.


> My guiding principle for API design is that one should always expose the
> fundamental building blocks as a low-level API, and then provide a smaller
> interface for the common use cases. Typeclass instances are no different -
> they are the general interface that allows us to invoke what is ultimately
> a monomorphic, low-level building block function in a polymorphic context.
>

This is exactly the opposite API design principle I have: Do not expose the
monomorphic functions if they are already in a type class. You can easily
reconstruct them as a library user via type signtures if this is really
needed (still haven't seen many convincing examples of that), but you can'
do it the other way round. Less things exposed, no generality/use cases
lost => easier to remember.

The thing we can probably agree on: API design is hard and it's not an
exact science, more a kind of art which is assessed in a subjective way...
:-)

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190823/417798b3/attachment.html>

From lemming at henning-thielemann.de  Mon Aug 26 13:19:43 2019
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 26 Aug 2019 15:19:43 +0200 (CEST)
Subject: Generalize runSTArray and runSTUArray
In-Reply-To: <CALKmN4_5JuqrJmcEr_EieMoSeg-C_BbobXuvdOkyedki8csOQg@mail.gmail.com>
References: <CAK7nUjjvU1Ot-TM6yiZ8McM4LssWGWzXP0Sq1L2NAK5pKauvVQ@mail.gmail.com>
 <alpine.DEB.2.20.1908220631430.6568@sputnik>
 <CALKmN4_5JuqrJmcEr_EieMoSeg-C_BbobXuvdOkyedki8csOQg@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1908261517540.3527@sputnik>


On Thu, 22 Aug 2019, Jonathan S wrote:

> Even simpler, Freezer could just be a Monad denoting arbitrary "cleanup" 
> actions, as long as they don't involve writes.

This was actually my first idea and I thought this would not be safe. But 
now I think you are right and this is both safe and more flexible.

From taylor at fausak.me  Wed Aug 28 02:21:38 2019
From: taylor at fausak.me (Taylor Fausak)
Date: Tue, 27 Aug 2019 22:21:38 -0400
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CANBN=mtF+wNJZTRWzS9O2b5ZXAe=PTo3rHf2+CFM00Wy2hSxGw@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <CAMgWh9v=qPwjKJEGWG4VeCk2nEfyk3NHiDm8dtWVUJVpwoaOCA@mail.gmail.com>
 <CAOFsAruKPpZUg9xwqo_j05SQs27rDbU5JqD71KJr646484OPoQ@mail.gmail.com>
 <CA+4qU96=MaH4FfM60F3Tv6VxaWDiXq9y3=k0vH29tLz9OzFncA@mail.gmail.com>
 <CAOFsArsSCaxNuxWuXByoyNx54SztjMVXwVz_gyRcLTuiWZOXUA@mail.gmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
 <CANBN=mtwprCF_MdX6EQkQzP75Y0hyBtPJtEZW6yZbhi9Cufxog@mail.gmail.com>
 <CANBN=muOJbKMutsQPKuF2JxTTLQQ70DoV5+0ZOyfSx9CumqoBQ@mail.gmail.com>
 <CAHFpbukqHTc-NDJ6waF_SEGDUyiZX0DpS0b8tzXd_31hweTUFg@mail.gmail.com>
 <CANBN=mtF+wNJZTRWzS9O2b5ZXAe=PTo3rHf2+CFM00Wy2hSxGw@mail.gmail.com>
Message-ID: <8bb76ec0-b07a-4190-99e0-cd2a1fc2aa10@www.fastmail.com>

It has been two weeks since I submitted this proposal, and one week since the core library committee started deliberating behind closed doors. Is there any visibility into the CLC's process, or at the very least a rough expected timeline?

On Fri, Aug 23, 2019, at 3:57 AM, Sven Panne wrote:
> Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe <kris.nuttycombe at gmail.com>:
>> 
>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne <svenpanne at gmail.com> wrote:
>>>  I think there's a significant difference between "little helper" and "the monomorphic function that is used to implement `pure`" - with a slightly different framing, we might be able to come to an agreement that both the monomorphic an polymorphic versions of this function are useful in different contexts. [...]
> 
> I think we can agree that we disagree here. ;-) My brain is too small to remember the names of myriads of trivial helpers, so I very much prefer general, orthogonal things. In our case: If we have a general, polymorphic function (often from a type class), just use that. If for some reason (rarely!) I want a more monomorphic function, I can just add a plain old type signature somewhere (no need for funky language extensions like type applications). This radically reduces the number of things one has to remember. In our case: Know type classes + know a way to make things more monomorphic.
> 
>>> 
>> My guiding principle for API design is that one should always expose the fundamental building blocks as a low-level API, and then provide a smaller interface for the common use cases. Typeclass instances are no different - they are the general interface that allows us to invoke what is ultimately a monomorphic, low-level building block function in a polymorphic context. 
> 
> This is exactly the opposite API design principle I have: Do not expose the monomorphic functions if they are already in a type class. You can easily reconstruct them as a library user via type signtures if this is really needed (still haven't seen many convincing examples of that), but you can' do it the other way round. Less things exposed, no generality/use cases lost => easier to remember.
> 
> The thing we can probably agree on: API design is hard and it's not an exact science, more a kind of art which is assessed in a subjective way... :-)
>> 
> _______________________________________________
> 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/20190827/7ef00a8a/attachment.html>

From keith.wygant at gmail.com  Wed Aug 28 19:57:24 2019
From: keith.wygant at gmail.com (Keith)
Date: Wed, 28 Aug 2019 19:57:24 +0000
Subject: Proposal: Add singleton function to Data.List module
In-Reply-To: <CANBN=mtF+wNJZTRWzS9O2b5ZXAe=PTo3rHf2+CFM00Wy2hSxGw@mail.gmail.com>
References: <d1487899-c14b-4226-8c59-7448af485f21@www.fastmail.com>
 <5D59678C.6030003@exmail.nottingham.ac.uk>
 <CAFgV2eZ25D-ggRH9m9xMJNHUhsjZhstqxDtGwkOh+dLPs3f42g@mail.gmail.com>
 <CAJNSRpFJK4pSWAWtjBAf0txRR4r_jvF2j4J9gdUqTAiTFVHaSQ@mail.gmail.com>
 <CAGRp5Rk8zTe4gpt17wtx6b+2u70=mFj8zD6-6tSeym+-MykxHQ@mail.gmail.com>
 <CAJNSRpF2tzj=TOAxQhE7QWLMQL8a65dHu2CjJjqrdd_9EYO5xA@mail.gmail.com>
 <b40df232-6a40-0e02-0234-3c5fecaa6ede@ifi.lmu.de>
 <CAJNSRpGDfeeVPVDijT7_34ixny9u-Hg0q-ZQ0_HTA591j0km0w@mail.gmail.com>
 <fe4f912a-6d76-4f9e-b5bb-33aaf69fcbd6@www.fastmail.com>
 <CABzzMayg3vYgyFiH=KLF1xfzg_0vWHoH8Dk6ydQ8TXLKhXRA-Q@mail.gmail.com>
 <CABhOzZjYMwwcjN5tJ4ks5XqRtuYWNtDgmn6w150mLX7w4O7Kyg@mail.gmail.com>
 <CANBN=mtwprCF_MdX6EQkQzP75Y0hyBtPJtEZW6yZbhi9Cufxog@mail.gmail.com>
 <CANBN=muOJbKMutsQPKuF2JxTTLQQ70DoV5+0ZOyfSx9CumqoBQ@mail.gmail.com>
 <CAHFpbukqHTc-NDJ6waF_SEGDUyiZX0DpS0b8tzXd_31hweTUFg@mail.gmail.com>
 <CANBN=mtF+wNJZTRWzS9O2b5ZXAe=PTo3rHf2+CFM00Wy2hSxGw@mail.gmail.com>
Message-ID: <55EB779D-809B-4686-AA4F-3B23BEBED8C3@gmail.com>

For what it's worth, when starting out I found the disconnect between list sugar and list constructor/destructors extremely confusing.
   In retrospect it seems pretty silly, but I could not figure out how lists were consumed as (x : xs) but often produced with [x, x1, ...]. Mistakes like [x, xs] were common.
   When I finally realized that I could construct lists with the list constuctors, I started using them exclusively.

Simplcity and straightforwardness help understanding. It was much easier for me to understand a singleton list as (x : []) than [x]. Having to deal with '(singleton x)' (at the time not knowing the definition of 'singleton') would have been another layer of confusion.

I get that 'singleton' is library design, since in shows up in Map, Array, Set, etc. But for me trying to use lists, it would have only been useful if I defined it myself as a way to learn that constuctors are fuctions, and that 'singleton' means 'single'.

On August 23, 2019 7:56:41 AM UTC, Sven Panne <svenpanne at gmail.com> wrote:
>Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe <
>kris.nuttycombe at gmail.com>:
>
>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne <svenpanne at gmail.com>
>wrote:
>>
>>>  I think there's a significant difference between "little helper"
>and
>>> "the monomorphic function that is used to implement `pure`" - with a
>>> slightly different framing, we might be able to come to an agreement
>that
>>> both the monomorphic an polymorphic versions of this function are
>useful in
>>> different contexts. [...]
>>>
>>
>I think we can agree that we disagree here. ;-) My brain is too small
>to
>remember the names of myriads of trivial helpers, so I very much prefer
>general, orthogonal things. In our case: If we have a general,
>polymorphic
>function (often from a type class), just use that. If for some reason
>(rarely!) I want a more monomorphic function, I can just add a plain
>old
>type signature somewhere (no need for funky language extensions like
>type
>applications). This radically reduces the number of things one has to
>remember. In our case: Know type classes + know a way to make things
>more
>monomorphic.
>
>
>> My guiding principle for API design is that one should always expose
>the
>> fundamental building blocks as a low-level API, and then provide a
>smaller
>> interface for the common use cases. Typeclass instances are no
>different -
>> they are the general interface that allows us to invoke what is
>ultimately
>> a monomorphic, low-level building block function in a polymorphic
>context.
>>
>
>This is exactly the opposite API design principle I have: Do not expose
>the
>monomorphic functions if they are already in a type class. You can
>easily
>reconstruct them as a library user via type signtures if this is really
>needed (still haven't seen many convincing examples of that), but you
>can'
>do it the other way round. Less things exposed, no generality/use cases
>lost => easier to remember.
>
>The thing we can probably agree on: API design is hard and it's not an
>exact science, more a kind of art which is assessed in a subjective
>way...
>:-)
>
>>

Keith
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190828/2f935e77/attachment.html>

From ndospark320 at gmail.com  Wed Aug 28 22:16:34 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Thu, 29 Aug 2019 07:16:34 +0900
Subject: Faster complex number multiplication
Message-ID: <CAKM3oZVObkzy-PUePj8huEs8DFN6a0Ly1O6dZWkrQUh0Ps1Kag@mail.gmail.com>

It is possible to have 3 multiplications rather than 4:

https://en.m.wikipedia.org/wiki/Multiplication_algorithm#Complex_multiplication_algorithm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190829/b92dca16/attachment.html>

From lemming at henning-thielemann.de  Wed Aug 28 22:31:22 2019
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 29 Aug 2019 00:31:22 +0200 (CEST)
Subject: Faster complex number multiplication
In-Reply-To: <CAKM3oZVObkzy-PUePj8huEs8DFN6a0Ly1O6dZWkrQUh0Ps1Kag@mail.gmail.com>
References: <CAKM3oZVObkzy-PUePj8huEs8DFN6a0Ly1O6dZWkrQUh0Ps1Kag@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1908290031020.21734@sputnik>


On Thu, 29 Aug 2019, Dannyu NDos wrote:

> It is possible to have 3 multiplications rather than 4:
> https://en.m.wikipedia.org/wiki/Multiplication_algorithm#Complex_multiplication_algorithm

But it is less precise, right?

From ndospark320 at gmail.com  Wed Aug 28 22:34:48 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Thu, 29 Aug 2019 07:34:48 +0900
Subject: Faster complex number multiplication
In-Reply-To: <alpine.DEB.2.20.1908290031020.21734@sputnik>
References: <CAKM3oZVObkzy-PUePj8huEs8DFN6a0Ly1O6dZWkrQUh0Ps1Kag@mail.gmail.com>
 <alpine.DEB.2.20.1908290031020.21734@sputnik>
Message-ID: <CAKM3oZVS4QPb3PP0wrO+hRN6Wf1iXo3BkocsMdeZ6Hjxh2oYLA@mail.gmail.com>

"There is a trade-off in that there may be some loss of precision when
using floating point." Says Wikipedia. :(

2019년 8월 29일 (목) 07:31, Henning Thielemann <lemming at henning-thielemann.de>님이
작성:

>
> On Thu, 29 Aug 2019, Dannyu NDos wrote:
>
> > It is possible to have 3 multiplications rather than 4:
> >
> https://en.m.wikipedia.org/wiki/Multiplication_algorithm#Complex_multiplication_algorithm
>
> But it is less precise, right?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190829/203e7459/attachment.html>

From zemyla at gmail.com  Wed Aug 28 23:48:33 2019
From: zemyla at gmail.com (Zemyla)
Date: Wed, 28 Aug 2019 18:48:33 -0500
Subject: Faster complex number multiplication
In-Reply-To: <CAKM3oZVS4QPb3PP0wrO+hRN6Wf1iXo3BkocsMdeZ6Hjxh2oYLA@mail.gmail.com>
References: <CAKM3oZVObkzy-PUePj8huEs8DFN6a0Ly1O6dZWkrQUh0Ps1Kag@mail.gmail.com>
 <alpine.DEB.2.20.1908290031020.21734@sputnik>
 <CAKM3oZVS4QPb3PP0wrO+hRN6Wf1iXo3BkocsMdeZ6Hjxh2oYLA@mail.gmail.com>
Message-ID: <CAK7nUjg=URm+tuWcZDx1CuwqmUOw5-2SGZYWn4vhs7xz53sjwQ@mail.gmail.com>

Also, on modern chips, Float and Double multiplication is practically the
same speed as addition.

On Wed, Aug 28, 2019, 17:35 Dannyu NDos <ndospark320 at gmail.com> wrote:

> "There is a trade-off in that there may be some loss of precision when
> using floating point." Says Wikipedia. :(
>
> 2019년 8월 29일 (목) 07:31, Henning Thielemann <lemming at henning-thielemann.de>님이
> 작성:
>
>>
>> On Thu, 29 Aug 2019, Dannyu NDos wrote:
>>
>> > It is possible to have 3 multiplications rather than 4:
>> >
>> https://en.m.wikipedia.org/wiki/Multiplication_algorithm#Complex_multiplication_algorithm
>>
>> But it is less precise, right?
>>
> _______________________________________________
> 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/20190828/e6d9a744/attachment.html>

From lemming at henning-thielemann.de  Wed Aug 28 23:51:28 2019
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 29 Aug 2019 01:51:28 +0200 (CEST)
Subject: Faster complex number multiplication
In-Reply-To: <CAK7nUjg=URm+tuWcZDx1CuwqmUOw5-2SGZYWn4vhs7xz53sjwQ@mail.gmail.com>
References: <CAKM3oZVObkzy-PUePj8huEs8DFN6a0Ly1O6dZWkrQUh0Ps1Kag@mail.gmail.com>
 <alpine.DEB.2.20.1908290031020.21734@sputnik>
 <CAKM3oZVS4QPb3PP0wrO+hRN6Wf1iXo3BkocsMdeZ6Hjxh2oYLA@mail.gmail.com>
 <CAK7nUjg=URm+tuWcZDx1CuwqmUOw5-2SGZYWn4vhs7xz53sjwQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1908290150290.21734@sputnik>


On Wed, 28 Aug 2019, Zemyla wrote:

> Also, on modern chips, Float and Double multiplication is practically 
> the same speed as addition.

But modern chips can also fuse multiplication and addition.

However this combines more dependencies in one operation and thus it may 
slow down, again.

From ndospark320 at gmail.com  Fri Aug 30 02:57:07 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Fri, 30 Aug 2019 11:57:07 +0900
Subject: long double
Message-ID: <CAKM3oZWD20uyXfMM2prGaeQc44ftXN19LS+orvf7+2zz5LL+7w@mail.gmail.com>

Could we implement IEEE quadruple-precision (binary128) format?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190830/f3dca013/attachment.html>

From mpeddie at gmail.com  Fri Aug 30 03:16:39 2019
From: mpeddie at gmail.com (Matt Peddie)
Date: Fri, 30 Aug 2019 13:16:39 +1000
Subject: long double
In-Reply-To: <CAKM3oZWD20uyXfMM2prGaeQc44ftXN19LS+orvf7+2zz5LL+7w@mail.gmail.com>
References: <CAKM3oZWD20uyXfMM2prGaeQc44ftXN19LS+orvf7+2zz5LL+7w@mail.gmail.com>
Message-ID: <CAAwKdvhx72NOf-K0Lj7U8TZwi6bzbbkmXX93sPCf4_9S9kH_Nw@mail.gmail.com>

Hi Dannyu NDos,

Have you seen the qd package (https://hackage.haskell.org/package/qd)
?  Is this insufficient for your needs?

Matt

On Fri, Aug 30, 2019 at 12:57 PM Dannyu NDos <ndospark320 at gmail.com> wrote:
>
> Could we implement IEEE quadruple-precision (binary128) format?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From ndospark320 at gmail.com  Fri Aug 30 03:25:21 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Fri, 30 Aug 2019 12:25:21 +0900
Subject: long double
In-Reply-To: <CAAwKdvhx72NOf-K0Lj7U8TZwi6bzbbkmXX93sPCf4_9S9kH_Nw@mail.gmail.com>
References: <CAKM3oZWD20uyXfMM2prGaeQc44ftXN19LS+orvf7+2zz5LL+7w@mail.gmail.com>
 <CAAwKdvhx72NOf-K0Lj7U8TZwi6bzbbkmXX93sPCf4_9S9kH_Nw@mail.gmail.com>
Message-ID: <CAKM3oZVOzDZFfSi4y4GeneZE7oT7o-HR4bqkQCc7uysu+_KdjQ@mail.gmail.com>

That package requires use of IO monad. I'd like if long double works as
that of C's.

2019년 8월 30일 (금) 12:16, Matt Peddie <mpeddie at gmail.com>님이 작성:

> Hi Dannyu NDos,
>
> Have you seen the qd package (https://hackage.haskell.org/package/qd)
> ?  Is this insufficient for your needs?
>
> Matt
>
> On Fri, Aug 30, 2019 at 12:57 PM Dannyu NDos <ndospark320 at gmail.com>
> wrote:
> >
> > Could we implement IEEE quadruple-precision (binary128) format?
> > _______________________________________________
> > 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/20190830/e758c133/attachment.html>

From ndospark320 at gmail.com  Fri Aug 30 03:30:05 2019
From: ndospark320 at gmail.com (Dannyu NDos)
Date: Fri, 30 Aug 2019 12:30:05 +0900
Subject: long double
In-Reply-To: <CAAwKdvhx72NOf-K0Lj7U8TZwi6bzbbkmXX93sPCf4_9S9kH_Nw@mail.gmail.com>
References: <CAKM3oZWD20uyXfMM2prGaeQc44ftXN19LS+orvf7+2zz5LL+7w@mail.gmail.com>
 <CAAwKdvhx72NOf-K0Lj7U8TZwi6bzbbkmXX93sPCf4_9S9kH_Nw@mail.gmail.com>
Message-ID: <CAKM3oZXkkOC+bg4-5OFk9O54TTmfQw2jQEWjzcqsOrhmjkBnfQ@mail.gmail.com>

I see long-double package is suitable:
http://hackage.haskell.org/package/long-double

Could we officially adopt it?

2019년 8월 30일 (금) 12:16, Matt Peddie <mpeddie at gmail.com>님이 작성:

> Hi Dannyu NDos,
>
> Have you seen the qd package (https://hackage.haskell.org/package/qd)
> ?  Is this insufficient for your needs?
>
> Matt
>
> On Fri, Aug 30, 2019 at 12:57 PM Dannyu NDos <ndospark320 at gmail.com>
> wrote:
> >
> > Could we implement IEEE quadruple-precision (binary128) format?
> > _______________________________________________
> > 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/20190830/514193b9/attachment.html>

From david.feuer at gmail.com  Fri Aug 30 03:30:12 2019
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 29 Aug 2019 23:30:12 -0400
Subject: long double
In-Reply-To: <CAKM3oZVOzDZFfSi4y4GeneZE7oT7o-HR4bqkQCc7uysu+_KdjQ@mail.gmail.com>
References: <CAKM3oZWD20uyXfMM2prGaeQc44ftXN19LS+orvf7+2zz5LL+7w@mail.gmail.com>
 <CAAwKdvhx72NOf-K0Lj7U8TZwi6bzbbkmXX93sPCf4_9S9kH_Nw@mail.gmail.com>
 <CAKM3oZVOzDZFfSi4y4GeneZE7oT7o-HR4bqkQCc7uysu+_KdjQ@mail.gmail.com>
Message-ID: <CAMgWh9ve9FP3Ui3X_Tb4=U3e11RWNcBum-RkRu0j_V4GLPsS5w@mail.gmail.com>

You're looking in the wrong module. See Numeric.QD.DoubleDouble.

On Thu, Aug 29, 2019, 11:25 PM Dannyu NDos <ndospark320 at gmail.com> wrote:

> That package requires use of IO monad. I'd like if long double works as
> that of C's.
>
> 2019년 8월 30일 (금) 12:16, Matt Peddie <mpeddie at gmail.com>님이 작성:
>
>> Hi Dannyu NDos,
>>
>> Have you seen the qd package (https://hackage.haskell.org/package/qd)
>> ?  Is this insufficient for your needs?
>>
>> Matt
>>
>> On Fri, Aug 30, 2019 at 12:57 PM Dannyu NDos <ndospark320 at gmail.com>
>> wrote:
>> >
>> > Could we implement IEEE quadruple-precision (binary128) format?
>> > _______________________________________________
>> > 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/20190829/5de49eac/attachment.html>

From lemming at henning-thielemann.de  Fri Aug 30 05:53:17 2019
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 30 Aug 2019 07:53:17 +0200 (CEST)
Subject: long double
In-Reply-To: <CAKM3oZWD20uyXfMM2prGaeQc44ftXN19LS+orvf7+2zz5LL+7w@mail.gmail.com>
References: <CAKM3oZWD20uyXfMM2prGaeQc44ftXN19LS+orvf7+2zz5LL+7w@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1908300752200.3683@sputnik>


On Fri, 30 Aug 2019, Dannyu NDos wrote:

> Could we implement IEEE quadruple-precision (binary128) format?

I think this is a pure Haskell implementation of the idea of representing 
high precision floats as sums of low precision floats:
    https://hackage.haskell.org/package/compensated

From carter.schonwald at gmail.com  Fri Aug 30 10:37:50 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 30 Aug 2019 06:37:50 -0400
Subject: long double
In-Reply-To: <alpine.DEB.2.20.1908300752200.3683@sputnik>
References: <CAKM3oZWD20uyXfMM2prGaeQc44ftXN19LS+orvf7+2zz5LL+7w@mail.gmail.com>
 <alpine.DEB.2.20.1908300752200.3683@sputnik>
Message-ID: <CAHYVw0z+0TOUh_SEyH=VcF8Xqi1y27afHkSr-osdpygeL5xvUA@mail.gmail.com>

Yeah compensated is a great foundation. Bear in mind that is can’t do as
extreme a dynamic range as a vanilla quad double but will be good for extra
precision.

On Fri, Aug 30, 2019 at 1:53 AM Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Fri, 30 Aug 2019, Dannyu NDos wrote:
>
> > Could we implement IEEE quadruple-precision (binary128) format?
>
> I think this is a pure Haskell implementation of the idea of representing
> high precision floats as sums of low precision floats:
>     https://hackage.haskell.org/package/compensated
> _______________________________________________
> 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/20190830/9caee83a/attachment.html>

From lexi.lambda at gmail.com  Fri Aug 30 18:16:04 2019
From: lexi.lambda at gmail.com (Alexis King)
Date: Fri, 30 Aug 2019 13:16:04 -0500
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
Message-ID: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>

Hi all,

In recent years, the DefaultSignatures extension has seen popular use as a mechanism for providing derived typeclass instances via GHC.Generics. Although undeniably useful, I have always felt it is somewhat ugly: it is mutually exclusive with other, non-Generic default method implementations, and it can only be used for one Generic deriving mechanism, so implementations must choose between GHC.Generics and Data.Data.

Fortunately, with the advent of DerivingVia, there is a better way: simply attach generic instances to a separate newtype, defined like

newtype Generically a = Generically { unGenerically :: a }

instance Generic a => C (Generically a) where
  ...

then derive instances using DerivingVia as follows:

data Foo = Bar X | Baz Y Z
  deriving C via Generically Foo

The `Generically` name already exists for this purpose in the `generic-data` package, making it a good candidate name for a newtype in GHC.Generics (`generic-data` could simply re-export the type with suitably recent versions of `base`). An alternate name would be the more traditional `WrappedGeneric`. I don’t have much of a preference either way, but I do think the `Generically` name is cute, especially when used with DerivingVia.

I believe this type should be in `base` because it is

(1) clearly generally useful in the same way that similar newtypes in `base` like `WrappedMonad` are (and probably even more so),

(2) extremely lightweight in terms of additional API complexity (it’s just a newtype),

(3) isn’t worth depending on a separate package for, encouraging a proliferation of (possibly name-conflicting) newtypes in individual packages if it isn’t in `base`, and

(4) is an opportunity to add instances based on `Generic` for classes already in `base`.

Overall, it’s something that would feel right at home in GHC.Generics to me.

As a final note, whichever name people prefer, it would of course make sense to provide an analogous `Generically1` or `WrappedGeneric1` type for `Generic1` (as `generic-data` does as well).

Alexis

From david.feuer at gmail.com  Fri Aug 30 18:18:27 2019
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 30 Aug 2019 14:18:27 -0400
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
Message-ID: <CAMgWh9t3e41VBeqVo0mF-RS0AQPCfGkx_MwdTyoDFKx1cc5gxg@mail.gmail.com>

That is an absolutely *beautiful* idea. I love it to pieces. I'm not fussy
about the name, but Generically does have a nice ring to it.

On Fri, Aug 30, 2019, 2:16 PM Alexis King <lexi.lambda at gmail.com> wrote:

> Hi all,
>
> In recent years, the DefaultSignatures extension has seen popular use as a
> mechanism for providing derived typeclass instances via GHC.Generics.
> Although undeniably useful, I have always felt it is somewhat ugly: it is
> mutually exclusive with other, non-Generic default method implementations,
> and it can only be used for one Generic deriving mechanism, so
> implementations must choose between GHC.Generics and Data.Data.
>
> Fortunately, with the advent of DerivingVia, there is a better way: simply
> attach generic instances to a separate newtype, defined like
>
> newtype Generically a = Generically { unGenerically :: a }
>
> instance Generic a => C (Generically a) where
>   ...
>
> then derive instances using DerivingVia as follows:
>
> data Foo = Bar X | Baz Y Z
>   deriving C via Generically Foo
>
> The `Generically` name already exists for this purpose in the
> `generic-data` package, making it a good candidate name for a newtype in
> GHC.Generics (`generic-data` could simply re-export the type with suitably
> recent versions of `base`). An alternate name would be the more traditional
> `WrappedGeneric`. I don’t have much of a preference either way, but I do
> think the `Generically` name is cute, especially when used with DerivingVia.
>
> I believe this type should be in `base` because it is
>
> (1) clearly generally useful in the same way that similar newtypes in
> `base` like `WrappedMonad` are (and probably even more so),
>
> (2) extremely lightweight in terms of additional API complexity (it’s just
> a newtype),
>
> (3) isn’t worth depending on a separate package for, encouraging a
> proliferation of (possibly name-conflicting) newtypes in individual
> packages if it isn’t in `base`, and
>
> (4) is an opportunity to add instances based on `Generic` for classes
> already in `base`.
>
> Overall, it’s something that would feel right at home in GHC.Generics to
> me.
>
> As a final note, whichever name people prefer, it would of course make
> sense to provide an analogous `Generically1` or `WrappedGeneric1` type for
> `Generic1` (as `generic-data` does as well).
>
> Alexis
> _______________________________________________
> 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/20190830/7abada5f/attachment.html>

From ollie at ocharles.org.uk  Fri Aug 30 18:26:51 2019
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Fri, 30 Aug 2019 19:26:51 +0100
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <CAMgWh9t3e41VBeqVo0mF-RS0AQPCfGkx_MwdTyoDFKx1cc5gxg@mail.gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
 <CAMgWh9t3e41VBeqVo0mF-RS0AQPCfGkx_MwdTyoDFKx1cc5gxg@mail.gmail.com>
Message-ID: <CAGRp5R=OdXHKejWmvSVyvTHPBRopy__mjx5R6ZOM8hNOyH9Gyw@mail.gmail.com>

Thanks for suggesting the Alexis, I've been thinking about exactly the same
thing, albeit for other generics libraries. It would be great to have this
in GHC.Generics. I'm a +1.

I haven't really thought it out, but I wonder if

newtype GenericallyUsing a c

Also works, paving the way for other generic classes. This would let you
write

data Foo = Bar X | Baz Y Z
  deriving C via Foo `GenericallyUsing` GHC.Generics.Generic

But you could also swap in SOP. This does mean instances of
GenericallyUsing would probably need Flexible instances though, and it does
complicate things.

Just throwing that out there!

Ollie

On Fri, 30 Aug 2019, 7:18 pm David Feuer, <david.feuer at gmail.com> wrote:

> That is an absolutely *beautiful* idea. I love it to pieces. I'm not fussy
> about the name, but Generically does have a nice ring to it.
>
> On Fri, Aug 30, 2019, 2:16 PM Alexis King <lexi.lambda at gmail.com> wrote:
>
>> Hi all,
>>
>> In recent years, the DefaultSignatures extension has seen popular use as
>> a mechanism for providing derived typeclass instances via GHC.Generics.
>> Although undeniably useful, I have always felt it is somewhat ugly: it is
>> mutually exclusive with other, non-Generic default method implementations,
>> and it can only be used for one Generic deriving mechanism, so
>> implementations must choose between GHC.Generics and Data.Data.
>>
>> Fortunately, with the advent of DerivingVia, there is a better way:
>> simply attach generic instances to a separate newtype, defined like
>>
>> newtype Generically a = Generically { unGenerically :: a }
>>
>> instance Generic a => C (Generically a) where
>>   ...
>>
>> then derive instances using DerivingVia as follows:
>>
>> data Foo = Bar X | Baz Y Z
>>   deriving C via Generically Foo
>>
>> The `Generically` name already exists for this purpose in the
>> `generic-data` package, making it a good candidate name for a newtype in
>> GHC.Generics (`generic-data` could simply re-export the type with suitably
>> recent versions of `base`). An alternate name would be the more traditional
>> `WrappedGeneric`. I don’t have much of a preference either way, but I do
>> think the `Generically` name is cute, especially when used with DerivingVia.
>>
>> I believe this type should be in `base` because it is
>>
>> (1) clearly generally useful in the same way that similar newtypes in
>> `base` like `WrappedMonad` are (and probably even more so),
>>
>> (2) extremely lightweight in terms of additional API complexity (it’s
>> just a newtype),
>>
>> (3) isn’t worth depending on a separate package for, encouraging a
>> proliferation of (possibly name-conflicting) newtypes in individual
>> packages if it isn’t in `base`, and
>>
>> (4) is an opportunity to add instances based on `Generic` for classes
>> already in `base`.
>>
>> Overall, it’s something that would feel right at home in GHC.Generics to
>> me.
>>
>> As a final note, whichever name people prefer, it would of course make
>> sense to provide an analogous `Generically1` or `WrappedGeneric1` type for
>> `Generic1` (as `generic-data` does as well).
>>
>> Alexis
>> _______________________________________________
>> 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/20190830/474a13f6/attachment.html>

From lexi.lambda at gmail.com  Fri Aug 30 18:50:41 2019
From: lexi.lambda at gmail.com (Alexis King)
Date: Fri, 30 Aug 2019 13:50:41 -0500
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <CAGRp5R=OdXHKejWmvSVyvTHPBRopy__mjx5R6ZOM8hNOyH9Gyw@mail.gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
 <CAMgWh9t3e41VBeqVo0mF-RS0AQPCfGkx_MwdTyoDFKx1cc5gxg@mail.gmail.com>
 <CAGRp5R=OdXHKejWmvSVyvTHPBRopy__mjx5R6ZOM8hNOyH9Gyw@mail.gmail.com>
Message-ID: <07AF08D8-36FC-49CA-8554-1E2734DFCD3D@gmail.com>

> On Aug 30, 2019, at 13:26, Oliver Charles <ollie at ocharles.org.uk> wrote:

> 
> I haven't really thought it out, but I wonder if
> 
> newtype GenericallyUsing a c
> 
> Also works, paving the way for other generic classes.

I don’t think this really adds anything over just having two newtypes, personally. `generics-sop` could, of course, always export its own newtype for this purpose, also named `Generically` or otherwise, and I think that would be simpler without any real disadvantages. I don’t think there are very many situations where you could be usefully polymorphic in the second type parameter of `GenericallyUsing`.


From ollie at ocharles.org.uk  Fri Aug 30 18:51:18 2019
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Fri, 30 Aug 2019 19:51:18 +0100
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <07AF08D8-36FC-49CA-8554-1E2734DFCD3D@gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
 <CAMgWh9t3e41VBeqVo0mF-RS0AQPCfGkx_MwdTyoDFKx1cc5gxg@mail.gmail.com>
 <CAGRp5R=OdXHKejWmvSVyvTHPBRopy__mjx5R6ZOM8hNOyH9Gyw@mail.gmail.com>
 <07AF08D8-36FC-49CA-8554-1E2734DFCD3D@gmail.com>
Message-ID: <CAGRp5Rm-LT+x0zqn7eCZHtCPFCoS1N5NPk34W7ZtBxzHTb-ckw@mail.gmail.com>

Yea, that's fair.

On Fri, 30 Aug 2019, 7:50 pm Alexis King, <lexi.lambda at gmail.com> wrote:

> > On Aug 30, 2019, at 13:26, Oliver Charles <ollie at ocharles.org.uk> wrote:
>
> >
> > I haven't really thought it out, but I wonder if
> >
> > newtype GenericallyUsing a c
> >
> > Also works, paving the way for other generic classes.
>
> I don’t think this really adds anything over just having two newtypes,
> personally. `generics-sop` could, of course, always export its own newtype
> for this purpose, also named `Generically` or otherwise, and I think that
> would be simpler without any real disadvantages. I don’t think there are
> very many situations where you could be usefully polymorphic in the second
> type parameter of `GenericallyUsing`.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190830/96b54111/attachment.html>

From david.feuer at gmail.com  Fri Aug 30 19:33:23 2019
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 30 Aug 2019 15:33:23 -0400
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
Message-ID: <CAMgWh9ukaLAT9dOW0dOXcwfgErJzD=-suxbtky=FJB80eQfxXQ@mail.gmail.com>

I do have two concerns:

1. The Genetically instances for base classes will need to move to base as
well, including auxiliary classes where those are needed.

2. The Generic instance of Generically is currently a custom job. That's
really not the greatest situation in general. Is that essential for some
reason? If not, I think its Generic instance should just be derived.

On Fri, Aug 30, 2019, 2:16 PM Alexis King <lexi.lambda at gmail.com> wrote:

> Hi all,
>
> In recent years, the DefaultSignatures extension has seen popular use as a
> mechanism for providing derived typeclass instances via GHC.Generics.
> Although undeniably useful, I have always felt it is somewhat ugly: it is
> mutually exclusive with other, non-Generic default method implementations,
> and it can only be used for one Generic deriving mechanism, so
> implementations must choose between GHC.Generics and Data.Data.
>
> Fortunately, with the advent of DerivingVia, there is a better way: simply
> attach generic instances to a separate newtype, defined like
>
> newtype Generically a = Generically { unGenerically :: a }
>
> instance Generic a => C (Generically a) where
>   ...
>
> then derive instances using DerivingVia as follows:
>
> data Foo = Bar X | Baz Y Z
>   deriving C via Generically Foo
>
> The `Generically` name already exists for this purpose in the
> `generic-data` package, making it a good candidate name for a newtype in
> GHC.Generics (`generic-data` could simply re-export the type with suitably
> recent versions of `base`). An alternate name would be the more traditional
> `WrappedGeneric`. I don’t have much of a preference either way, but I do
> think the `Generically` name is cute, especially when used with DerivingVia.
>
> I believe this type should be in `base` because it is
>
> (1) clearly generally useful in the same way that similar newtypes in
> `base` like `WrappedMonad` are (and probably even more so),
>
> (2) extremely lightweight in terms of additional API complexity (it’s just
> a newtype),
>
> (3) isn’t worth depending on a separate package for, encouraging a
> proliferation of (possibly name-conflicting) newtypes in individual
> packages if it isn’t in `base`, and
>
> (4) is an opportunity to add instances based on `Generic` for classes
> already in `base`.
>
> Overall, it’s something that would feel right at home in GHC.Generics to
> me.
>
> As a final note, whichever name people prefer, it would of course make
> sense to provide an analogous `Generically1` or `WrappedGeneric1` type for
> `Generic1` (as `generic-data` does as well).
>
> Alexis
> _______________________________________________
> 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/20190830/dfac2fb6/attachment.html>

From chessai1996 at gmail.com  Fri Aug 30 20:08:24 2019
From: chessai1996 at gmail.com (chessai .)
Date: Fri, 30 Aug 2019 16:08:24 -0400
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <CAMgWh9ukaLAT9dOW0dOXcwfgErJzD=-suxbtky=FJB80eQfxXQ@mail.gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
 <CAMgWh9ukaLAT9dOW0dOXcwfgErJzD=-suxbtky=FJB80eQfxXQ@mail.gmail.com>
Message-ID: <CAD34_kKb+xwadbbOrsVvTMteZeMxHN=+qfjdWMtvtKyzzZMRVw@mail.gmail.com>

+1

On Fri, Aug 30, 2019, 3:33 PM David Feuer <david.feuer at gmail.com> wrote:

> I do have two concerns:
>
> 1. The Genetically instances for base classes will need to move to base as
> well, including auxiliary classes where those are needed.
>
> 2. The Generic instance of Generically is currently a custom job. That's
> really not the greatest situation in general. Is that essential for some
> reason? If not, I think its Generic instance should just be derived.
>
> On Fri, Aug 30, 2019, 2:16 PM Alexis King <lexi.lambda at gmail.com> wrote:
>
>> Hi all,
>>
>> In recent years, the DefaultSignatures extension has seen popular use as
>> a mechanism for providing derived typeclass instances via GHC.Generics.
>> Although undeniably useful, I have always felt it is somewhat ugly: it is
>> mutually exclusive with other, non-Generic default method implementations,
>> and it can only be used for one Generic deriving mechanism, so
>> implementations must choose between GHC.Generics and Data.Data.
>>
>> Fortunately, with the advent of DerivingVia, there is a better way:
>> simply attach generic instances to a separate newtype, defined like
>>
>> newtype Generically a = Generically { unGenerically :: a }
>>
>> instance Generic a => C (Generically a) where
>>   ...
>>
>> then derive instances using DerivingVia as follows:
>>
>> data Foo = Bar X | Baz Y Z
>>   deriving C via Generically Foo
>>
>> The `Generically` name already exists for this purpose in the
>> `generic-data` package, making it a good candidate name for a newtype in
>> GHC.Generics (`generic-data` could simply re-export the type with suitably
>> recent versions of `base`). An alternate name would be the more traditional
>> `WrappedGeneric`. I don’t have much of a preference either way, but I do
>> think the `Generically` name is cute, especially when used with DerivingVia.
>>
>> I believe this type should be in `base` because it is
>>
>> (1) clearly generally useful in the same way that similar newtypes in
>> `base` like `WrappedMonad` are (and probably even more so),
>>
>> (2) extremely lightweight in terms of additional API complexity (it’s
>> just a newtype),
>>
>> (3) isn’t worth depending on a separate package for, encouraging a
>> proliferation of (possibly name-conflicting) newtypes in individual
>> packages if it isn’t in `base`, and
>>
>> (4) is an opportunity to add instances based on `Generic` for classes
>> already in `base`.
>>
>> Overall, it’s something that would feel right at home in GHC.Generics to
>> me.
>>
>> As a final note, whichever name people prefer, it would of course make
>> sense to provide an analogous `Generically1` or `WrappedGeneric1` type for
>> `Generic1` (as `generic-data` does as well).
>>
>> Alexis
>> _______________________________________________
>> 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/20190830/64a3773c/attachment.html>

From chessai1996 at gmail.com  Fri Aug 30 20:08:42 2019
From: chessai1996 at gmail.com (chessai .)
Date: Fri, 30 Aug 2019 16:08:42 -0400
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <CAD34_kKb+xwadbbOrsVvTMteZeMxHN=+qfjdWMtvtKyzzZMRVw@mail.gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
 <CAMgWh9ukaLAT9dOW0dOXcwfgErJzD=-suxbtky=FJB80eQfxXQ@mail.gmail.com>
 <CAD34_kKb+xwadbbOrsVvTMteZeMxHN=+qfjdWMtvtKyzzZMRVw@mail.gmail.com>
Message-ID: <CAD34_kJQfHMys=Zqpp4vhSAesg4=xcptovDYASLM84An7pvW+Q@mail.gmail.com>

Been wanting this for a while now

On Fri, Aug 30, 2019, 4:08 PM chessai . <chessai1996 at gmail.com> wrote:

> +1
>
> On Fri, Aug 30, 2019, 3:33 PM David Feuer <david.feuer at gmail.com> wrote:
>
>> I do have two concerns:
>>
>> 1. The Genetically instances for base classes will need to move to base
>> as well, including auxiliary classes where those are needed.
>>
>> 2. The Generic instance of Generically is currently a custom job. That's
>> really not the greatest situation in general. Is that essential for some
>> reason? If not, I think its Generic instance should just be derived.
>>
>> On Fri, Aug 30, 2019, 2:16 PM Alexis King <lexi.lambda at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> In recent years, the DefaultSignatures extension has seen popular use as
>>> a mechanism for providing derived typeclass instances via GHC.Generics.
>>> Although undeniably useful, I have always felt it is somewhat ugly: it is
>>> mutually exclusive with other, non-Generic default method implementations,
>>> and it can only be used for one Generic deriving mechanism, so
>>> implementations must choose between GHC.Generics and Data.Data.
>>>
>>> Fortunately, with the advent of DerivingVia, there is a better way:
>>> simply attach generic instances to a separate newtype, defined like
>>>
>>> newtype Generically a = Generically { unGenerically :: a }
>>>
>>> instance Generic a => C (Generically a) where
>>>   ...
>>>
>>> then derive instances using DerivingVia as follows:
>>>
>>> data Foo = Bar X | Baz Y Z
>>>   deriving C via Generically Foo
>>>
>>> The `Generically` name already exists for this purpose in the
>>> `generic-data` package, making it a good candidate name for a newtype in
>>> GHC.Generics (`generic-data` could simply re-export the type with suitably
>>> recent versions of `base`). An alternate name would be the more traditional
>>> `WrappedGeneric`. I don’t have much of a preference either way, but I do
>>> think the `Generically` name is cute, especially when used with DerivingVia.
>>>
>>> I believe this type should be in `base` because it is
>>>
>>> (1) clearly generally useful in the same way that similar newtypes in
>>> `base` like `WrappedMonad` are (and probably even more so),
>>>
>>> (2) extremely lightweight in terms of additional API complexity (it’s
>>> just a newtype),
>>>
>>> (3) isn’t worth depending on a separate package for, encouraging a
>>> proliferation of (possibly name-conflicting) newtypes in individual
>>> packages if it isn’t in `base`, and
>>>
>>> (4) is an opportunity to add instances based on `Generic` for classes
>>> already in `base`.
>>>
>>> Overall, it’s something that would feel right at home in GHC.Generics to
>>> me.
>>>
>>> As a final note, whichever name people prefer, it would of course make
>>> sense to provide an analogous `Generically1` or `WrappedGeneric1` type for
>>> `Generic1` (as `generic-data` does as well).
>>>
>>> Alexis
>>> _______________________________________________
>>> 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/20190830/2af8c307/attachment.html>

From lexi.lambda at gmail.com  Fri Aug 30 20:11:23 2019
From: lexi.lambda at gmail.com (Alexis King)
Date: Fri, 30 Aug 2019 15:11:23 -0500
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <CAMgWh9ukaLAT9dOW0dOXcwfgErJzD=-suxbtky=FJB80eQfxXQ@mail.gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
 <CAMgWh9ukaLAT9dOW0dOXcwfgErJzD=-suxbtky=FJB80eQfxXQ@mail.gmail.com>
Message-ID: <527F9626-0A54-403C-B25A-3A4AB177FCCC@gmail.com>

> On Aug 30, 2019, at 14:33, David Feuer <david.feuer at gmail.com> wrote:
> 
> I do have two concerns:
> 
> 1. The Genetically instances for base classes will need to move to base as well, including auxiliary classes where those are needed.

Agreed. For context, the existing instances of Generically (apart from the Generic instance, discussed below) are:

(Generic a, Eq (Rep a ())) => Eq (Generically a)
(Generic a, Ord (Rep a ())) => Ord (Generically a)
(Generic a, GBounded (Rep a)) => Bounded (Generically a)
(Generic a, GEnum StandardEnum (Rep a)) => Enum (Generically a)
(Generic a, GShow0 (Rep a)) => Show (Generically a)
(Generic a, Semigroup (Rep a ())) => Semigroup (Generically a)
(Semigroup a, Generic a, Monoid (Rep a ())) => Monoid (Generically a)

I think having these in `base` is actually a good thing, since it serves as a good set of examples of how to use GHC.Generics. The current `GEnum` class might be a little too much to include in `base`, but that’s fine: it can be specialized to `GEnum StandardEnum` without breaking backwards-compatibility with `generic-data` (which can continue to provide the more sophisticated implementation).

> 2. The Generic instance of Generically is currently a custom job. That's really not the greatest situation in general. Is that essential for some reason? If not, I think its Generic instance should just be derived.

This is an interesting point. Again for context, the current instance is as follows:

instance Generic a => Generic (Generically a) where
  type Rep (Generically a) = Rep a
  to = Generically . to
  from = from . unGenerically

Which is to say `Generically` wrappers are invisible from the perspective of the `Generic` class.

Personally, I think this instance makes sense: think of every instance of some class `C` on `Generically a` is supposed to provide an instance of `C a` in terms of `Generic a`, and that is exactly what `Generic (Generically a)` does. However, it’s obviously a useless instance, since it’s just the identity function on an existing `Generic a` dictionary. In any case, I think it’s harmless, but I can understand why you might think it’s sketchy.


From david.feuer at gmail.com  Fri Aug 30 21:46:14 2019
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 30 Aug 2019 17:46:14 -0400
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <527F9626-0A54-403C-B25A-3A4AB177FCCC@gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
 <CAMgWh9ukaLAT9dOW0dOXcwfgErJzD=-suxbtky=FJB80eQfxXQ@mail.gmail.com>
 <527F9626-0A54-403C-B25A-3A4AB177FCCC@gmail.com>
Message-ID: <CAMgWh9vg=V0Dv1V53O5+wXJ9VQr5-qCz8sJj5vRekUeKCt9EPA@mail.gmail.com>

I'm okay with moving those things into base. I'm even okay with doing some
fancy ad hoc thing with Enum (Enum is a bad joke anyway). But the Generic
instance gives me the heeby jeebies. Will it hurt anyone to just derive
Generic there? (And both Generic and Generic1 for Generically1?). I'd
rather not just omit it, but I think that would be better than this.

On Fri, Aug 30, 2019, 4:11 PM Alexis King <lexi.lambda at gmail.com> wrote:

> > On Aug 30, 2019, at 14:33, David Feuer <david.feuer at gmail.com> wrote:
> >
> > I do have two concerns:
> >
> > 1. The Genetically instances for base classes will need to move to base
> as well, including auxiliary classes where those are needed.
>
> Agreed. For context, the existing instances of Generically (apart from the
> Generic instance, discussed below) are:
>
> (Generic a, Eq (Rep a ())) => Eq (Generically a)
> (Generic a, Ord (Rep a ())) => Ord (Generically a)
> (Generic a, GBounded (Rep a)) => Bounded (Generically a)
> (Generic a, GEnum StandardEnum (Rep a)) => Enum (Generically a)
> (Generic a, GShow0 (Rep a)) => Show (Generically a)
> (Generic a, Semigroup (Rep a ())) => Semigroup (Generically a)
> (Semigroup a, Generic a, Monoid (Rep a ())) => Monoid (Generically a)
>
> I think having these in `base` is actually a good thing, since it serves
> as a good set of examples of how to use GHC.Generics. The current `GEnum`
> class might be a little too much to include in `base`, but that’s fine: it
> can be specialized to `GEnum StandardEnum` without breaking
> backwards-compatibility with `generic-data` (which can continue to provide
> the more sophisticated implementation).
>
> > 2. The Generic instance of Generically is currently a custom job. That's
> really not the greatest situation in general. Is that essential for some
> reason? If not, I think its Generic instance should just be derived.
>
> This is an interesting point. Again for context, the current instance is
> as follows:
>
> instance Generic a => Generic (Generically a) where
>   type Rep (Generically a) = Rep a
>   to = Generically . to
>   from = from . unGenerically
>
> Which is to say `Generically` wrappers are invisible from the perspective
> of the `Generic` class.
>
> Personally, I think this instance makes sense: think of every instance of
> some class `C` on `Generically a` is supposed to provide an instance of `C
> a` in terms of `Generic a`, and that is exactly what `Generic (Generically
> a)` does. However, it’s obviously a useless instance, since it’s just the
> identity function on an existing `Generic a` dictionary. In any case, I
> think it’s harmless, but I can understand why you might think it’s sketchy.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190830/81355f88/attachment.html>

From lexi.lambda at gmail.com  Fri Aug 30 22:26:49 2019
From: lexi.lambda at gmail.com (Alexis King)
Date: Fri, 30 Aug 2019 17:26:49 -0500
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <CAMgWh9vg=V0Dv1V53O5+wXJ9VQr5-qCz8sJj5vRekUeKCt9EPA@mail.gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
 <CAMgWh9ukaLAT9dOW0dOXcwfgErJzD=-suxbtky=FJB80eQfxXQ@mail.gmail.com>
 <527F9626-0A54-403C-B25A-3A4AB177FCCC@gmail.com>
 <CAMgWh9vg=V0Dv1V53O5+wXJ9VQr5-qCz8sJj5vRekUeKCt9EPA@mail.gmail.com>
Message-ID: <6596EEA0-AB50-4443-8A17-224482F48361@gmail.com>

I don’t think a derived `Generic` instance makes any more sense for `Generically` than a derived `Show` instance does. What would be the purpose of such an instance? Again, `instance C (Generically a)` is morally a function on dictionaries of type `Generic a -> C a`, and every instance on `Generically` should have that relationship. The existing `Generic` instance does, but a derived `Generic` instance would not.

If you want to leave that instance out, that’s fine with me; I highly doubt anyone would miss it. As I said before, it’s totally useless. But a derived `Generic` instance seems to have no purpose and would be inconsistent with the rules the other instances obey, so it seems strictly worse than no instance to me.

> On Aug 30, 2019, at 16:46, David Feuer <david.feuer at gmail.com> wrote:
> 
> I'm okay with moving those things into base. I'm even okay with doing some fancy ad hoc thing with Enum (Enum is a bad joke anyway). But the Generic instance gives me the heeby jeebies. Will it hurt anyone to just derive Generic there? (And both Generic and Generic1 for Generically1?). I'd rather not just omit it, but I think that would be better than this.
> 
> On Fri, Aug 30, 2019, 4:11 PM Alexis King <lexi.lambda at gmail.com <mailto:lexi.lambda at gmail.com>> wrote:
> > On Aug 30, 2019, at 14:33, David Feuer <david.feuer at gmail.com <mailto:david.feuer at gmail.com>> wrote:
> > 
> > I do have two concerns:
> > 
> > 1. The Genetically instances for base classes will need to move to base as well, including auxiliary classes where those are needed.
> 
> Agreed. For context, the existing instances of Generically (apart from the Generic instance, discussed below) are:
> 
> (Generic a, Eq (Rep a ())) => Eq (Generically a)
> (Generic a, Ord (Rep a ())) => Ord (Generically a)
> (Generic a, GBounded (Rep a)) => Bounded (Generically a)
> (Generic a, GEnum StandardEnum (Rep a)) => Enum (Generically a)
> (Generic a, GShow0 (Rep a)) => Show (Generically a)
> (Generic a, Semigroup (Rep a ())) => Semigroup (Generically a)
> (Semigroup a, Generic a, Monoid (Rep a ())) => Monoid (Generically a)
> 
> I think having these in `base` is actually a good thing, since it serves as a good set of examples of how to use GHC.Generics. The current `GEnum` class might be a little too much to include in `base`, but that’s fine: it can be specialized to `GEnum StandardEnum` without breaking backwards-compatibility with `generic-data` (which can continue to provide the more sophisticated implementation).
> 
> > 2. The Generic instance of Generically is currently a custom job. That's really not the greatest situation in general. Is that essential for some reason? If not, I think its Generic instance should just be derived.
> 
> This is an interesting point. Again for context, the current instance is as follows:
> 
> instance Generic a => Generic (Generically a) where
>   type Rep (Generically a) = Rep a
>   to = Generically . to
>   from = from . unGenerically
> 
> Which is to say `Generically` wrappers are invisible from the perspective of the `Generic` class.
> 
> Personally, I think this instance makes sense: think of every instance of some class `C` on `Generically a` is supposed to provide an instance of `C a` in terms of `Generic a`, and that is exactly what `Generic (Generically a)` does. However, it’s obviously a useless instance, since it’s just the identity function on an existing `Generic a` dictionary. In any case, I think it’s harmless, but I can understand why you might think it’s sketchy.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190830/44692d12/attachment.html>

From lexi.lambda at gmail.com  Sat Aug 31 00:25:57 2019
From: lexi.lambda at gmail.com (Alexis King)
Date: Fri, 30 Aug 2019 19:25:57 -0500
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <6596EEA0-AB50-4443-8A17-224482F48361@gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
 <CAMgWh9ukaLAT9dOW0dOXcwfgErJzD=-suxbtky=FJB80eQfxXQ@mail.gmail.com>
 <527F9626-0A54-403C-B25A-3A4AB177FCCC@gmail.com>
 <CAMgWh9vg=V0Dv1V53O5+wXJ9VQr5-qCz8sJj5vRekUeKCt9EPA@mail.gmail.com>
 <6596EEA0-AB50-4443-8A17-224482F48361@gmail.com>
Message-ID: <26ADC4D4-9B59-4FE9-AE5B-38F0BED6598F@gmail.com>

> On Aug 30, 2019, at 17:26, Alexis King <lexi.lambda at gmail.com> wrote:
> 
> If you want to leave that instance out, that’s fine with me; I highly doubt anyone would miss it. As I said before, it’s totally useless.

Actually, I take this back. It’s not totally useless, just unlikely to be useful (and ultimately inessential). It’s theoretically useful if you have some function like

     foo :: (Show a, Generic a) => a -> Foo

and want to use the generic version of the `Show` instance, but for some reason don’t want to actually define that instance on your type. You can write `foo (Generically x)`, and it will work out. That wouldn’t work if `Generic (Generically a)` were the derived instance.

On the other hand, you could always get the same behavior in a more flexible way by just defining a separate newtype and deriving the relevant instances as desired, like this:

     newtype GenericallyShowable a = GenericallyShowable a
         deriving newtype (Generic)
         deriving (Show) via Generically a

So the instance isn’t necessary by any means, nor does it seem particularly likely to be useful in practice, but it doesn’t seem impossible that it ever could be. My vote is to keep it; I don’t see the harm.


From david.feuer at gmail.com  Sat Aug 31 01:36:14 2019
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 30 Aug 2019 21:36:14 -0400
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <26ADC4D4-9B59-4FE9-AE5B-38F0BED6598F@gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
 <CAMgWh9ukaLAT9dOW0dOXcwfgErJzD=-suxbtky=FJB80eQfxXQ@mail.gmail.com>
 <527F9626-0A54-403C-B25A-3A4AB177FCCC@gmail.com>
 <CAMgWh9vg=V0Dv1V53O5+wXJ9VQr5-qCz8sJj5vRekUeKCt9EPA@mail.gmail.com>
 <6596EEA0-AB50-4443-8A17-224482F48361@gmail.com>
 <26ADC4D4-9B59-4FE9-AE5B-38F0BED6598F@gmail.com>
Message-ID: <CAMgWh9sz-cHQ=oXaaq4gWO_SEsGyBTz06NG4WCqoQb-jVSSmuw@mail.gmail.com>

It sounds like we can probably agree not to include the instance for now.
But I don't want to just go with my gut feeling, so here's a concrete
reason:

Generically isn't *just* a DerivingVia target: it's also a perfectly
reasonable newtype in its own right. Consider something like
CoercibleUtils.Newtype [*]. If you try to work `under Generically` with
your instance, then the type checker won't let you. That's rather sad, I
think, because it seems like a perfectly sensible thing to do.

[*]
https://github.com/sjakobi/coercible-utils/blob/072c60837059aaaac47628a1822c01fbb2baed6f/src/CoercibleUtils/Newtype.hs

On Fri, Aug 30, 2019, 8:26 PM Alexis King <lexi.lambda at gmail.com> wrote:

> > On Aug 30, 2019, at 17:26, Alexis King <lexi.lambda at gmail.com> wrote:
> >
> > If you want to leave that instance out, that’s fine with me; I highly
> doubt anyone would miss it. As I said before, it’s totally useless.
>
> Actually, I take this back. It’s not totally useless, just unlikely to be
> useful (and ultimately inessential). It’s theoretically useful if you have
> some function like
>
>      foo :: (Show a, Generic a) => a -> Foo
>
> and want to use the generic version of the `Show` instance, but for some
> reason don’t want to actually define that instance on your type. You can
> write `foo (Generically x)`, and it will work out. That wouldn’t work if
> `Generic (Generically a)` were the derived instance.
>
> On the other hand, you could always get the same behavior in a more
> flexible way by just defining a separate newtype and deriving the relevant
> instances as desired, like this:
>
>      newtype GenericallyShowable a = GenericallyShowable a
>          deriving newtype (Generic)
>          deriving (Show) via Generically a
>
> So the instance isn’t necessary by any means, nor does it seem
> particularly likely to be useful in practice, but it doesn’t seem
> impossible that it ever could be. My vote is to keep it; I don’t see the
> harm.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190830/15f3535e/attachment.html>

From nbouscal at gmail.com  Sat Aug 31 14:03:27 2019
From: nbouscal at gmail.com (Nathan Bouscal)
Date: Sat, 31 Aug 2019 15:03:27 +0100
Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to
 GHC.Generics
In-Reply-To: <CAMgWh9sz-cHQ=oXaaq4gWO_SEsGyBTz06NG4WCqoQb-jVSSmuw@mail.gmail.com>
References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com>
 <CAMgWh9ukaLAT9dOW0dOXcwfgErJzD=-suxbtky=FJB80eQfxXQ@mail.gmail.com>
 <527F9626-0A54-403C-B25A-3A4AB177FCCC@gmail.com>
 <CAMgWh9vg=V0Dv1V53O5+wXJ9VQr5-qCz8sJj5vRekUeKCt9EPA@mail.gmail.com>
 <6596EEA0-AB50-4443-8A17-224482F48361@gmail.com>
 <26ADC4D4-9B59-4FE9-AE5B-38F0BED6598F@gmail.com>
 <CAMgWh9sz-cHQ=oXaaq4gWO_SEsGyBTz06NG4WCqoQb-jVSSmuw@mail.gmail.com>
Message-ID: <CABhOzZiG8bg4kuM05LLPwrrk6LJyP3p7V+7CB+bmuTaTxatsyA@mail.gmail.com>

+1, this is a great idea

On Sat, Aug 31, 2019 at 2:36 AM David Feuer <david.feuer at gmail.com> wrote:

> It sounds like we can probably agree not to include the instance for now.
> But I don't want to just go with my gut feeling, so here's a concrete
> reason:
>
> Generically isn't *just* a DerivingVia target: it's also a perfectly
> reasonable newtype in its own right. Consider something like
> CoercibleUtils.Newtype [*]. If you try to work `under Generically` with
> your instance, then the type checker won't let you. That's rather sad, I
> think, because it seems like a perfectly sensible thing to do.
>
> [*]
> https://github.com/sjakobi/coercible-utils/blob/072c60837059aaaac47628a1822c01fbb2baed6f/src/CoercibleUtils/Newtype.hs
>
> On Fri, Aug 30, 2019, 8:26 PM Alexis King <lexi.lambda at gmail.com> wrote:
>
>> > On Aug 30, 2019, at 17:26, Alexis King <lexi.lambda at gmail.com> wrote:
>> >
>> > If you want to leave that instance out, that’s fine with me; I highly
>> doubt anyone would miss it. As I said before, it’s totally useless.
>>
>> Actually, I take this back. It’s not totally useless, just unlikely to be
>> useful (and ultimately inessential). It’s theoretically useful if you have
>> some function like
>>
>>      foo :: (Show a, Generic a) => a -> Foo
>>
>> and want to use the generic version of the `Show` instance, but for some
>> reason don’t want to actually define that instance on your type. You can
>> write `foo (Generically x)`, and it will work out. That wouldn’t work if
>> `Generic (Generically a)` were the derived instance.
>>
>> On the other hand, you could always get the same behavior in a more
>> flexible way by just defining a separate newtype and deriving the relevant
>> instances as desired, like this:
>>
>>      newtype GenericallyShowable a = GenericallyShowable a
>>          deriving newtype (Generic)
>>          deriving (Show) via Generically a
>>
>> So the instance isn’t necessary by any means, nor does it seem
>> particularly likely to be useful in practice, but it doesn’t seem
>> impossible that it ever could be. My vote is to keep it; I don’t see the
>> harm.
>>
>> _______________________________________________
> 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/20190831/72606140/attachment.html>