From fumiexcel at gmail.com  Fri Oct 15 02:31:19 2021
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Fri, 15 Oct 2021 11:31:19 +0900
Subject: Proposal: deprecate Prelude.read
Message-ID: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>

It is a partial function that does not provide a call stack, and it's very
slow too.

I propose deprecating Prelude.read. Adding deprecation should not break
anything substantial because Hackage rejects -Werror (application code
using -Werror is likely to experience a lot more breakage anyway, and I'd
say it's their fault if it fails to build due to a use of read along with
-Werror).

Of course those who still want to use Prelude.read can totally ignore
warnings. I believe this proposal is not that controversial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211015/15cd4786/attachment.html>

From emilypi at cohomolo.gy  Fri Oct 15 03:16:12 2021
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Fri, 15 Oct 2021 03:16:12 +0000
Subject: Proposal: deprecate Prelude.read
In-Reply-To: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>
References: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>
Message-ID: <kursg500.c742c55a-7a19-49ff-80d5-cc268ba38f58@we.are.superhuman.com>

NOPE.

On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita < fumiexcel at gmail.com > wrote:

> 
> It is a partial function that does not provide a call stack, and it's very
> slow too.
> 
> 
> 
> I propose deprecating Prelude. read ( http://prelude.read/ ). Adding
> deprecation should not break anything substantial because Hackage rejects
> -Werror (application code using -Werror is likely to experience a lot more
> breakage anyway, and I'd say it's their fault if it fails to build due to
> a use of read along with -Werror).
> 
> 
> Of course those who still want to use Prelude. read ( http://prelude.read/
> ) can totally ignore warnings. I believe this proposal is not that
> controversial.
> 
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries@ haskell. org ( Libraries at haskell.org )
> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries (
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries )
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211015/f09fbaef/attachment.html>

From david.feuer at gmail.com  Fri Oct 15 03:46:15 2021
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 14 Oct 2021 23:46:15 -0400
Subject: Proposal: deprecate Prelude.read
In-Reply-To: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>
References: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>
Message-ID: <CAMgWh9uTywg0WwAKNikkgBGg+3a3iDx3+0TWPYNtFgNjX_1Zmw@mail.gmail.com>

If it doesn't give a call stack, we can fix that. While I avoid using
it myself, and I think it's much better to use (at least)
Text.readMaybe, I'm not convinced that the breakage to existing
educational material is worth the benefit of actually removing it.

On Thu, Oct 14, 2021 at 10:31 PM Fumiaki Kinoshita <fumiexcel at gmail.com> wrote:
>
> It is a partial function that does not provide a call stack, and it's very slow too.
>
> I propose deprecating Prelude.read. Adding deprecation should not break anything substantial because Hackage rejects -Werror (application code using -Werror is likely to experience a lot more breakage anyway, and I'd say it's their fault if it fails to build due to a use of read along with -Werror).
>
> Of course those who still want to use Prelude.read can totally ignore warnings. I believe this proposal is not that controversial.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From ekmett at gmail.com  Fri Oct 15 03:47:07 2021
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 14 Oct 2021 23:47:07 -0400
Subject: Proposal: deprecate Prelude.read
In-Reply-To: <kursg500.c742c55a-7a19-49ff-80d5-cc268ba38f58@we.are.superhuman.com>
References: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>
 <kursg500.c742c55a-7a19-49ff-80d5-cc268ba38f58@we.are.superhuman.com>
Message-ID: <CAJumaK9g=G2F0pow9Eo=s1-nfcGe1=oq6CeBKv8X_EZeCyvmnw@mail.gmail.com>

A variant of this that I would support would be to bring readMaybe into
Prelude from Text.Read for a good long time, and *then* to deprecate read.
As it stands, read and the almost equally ugly readIO are the only Prelude
facing ways for a user to really consume a Read instance, so losing read
there is a heck of a blow to usability without a replacement being in place
with an established pattern of usage.

-Edward

On Thu, Oct 14, 2021 at 11:16 PM Emily Pillmore <emilypi at cohomolo.gy> wrote:

> NOPE.
>
>
> On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita <fumiexcel at gmail.com>
> wrote:
>
>> It is a partial function that does not provide a call stack, and it's
>> very slow too.
>>
>> I propose deprecating Prelude.read <http://prelude.read/>. Adding
>> deprecation should not break anything substantial because Hackage rejects
>> -Werror (application code using -Werror is likely to experience a lot more
>> breakage anyway, and I'd say it's their fault if it fails to build due to a
>> use of read along with -Werror).
>>
>> Of course those who still want to use Prelude.read <http://prelude.read/>
>> can totally ignore warnings. I believe this proposal is not that
>> controversial.
>>
>> _______________________________________________
>> 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/20211014/abfb9abd/attachment.html>

From carter.schonwald at gmail.com  Fri Oct 15 03:52:56 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 14 Oct 2021 23:52:56 -0400
Subject: Proposal: deprecate Prelude.read
In-Reply-To: <CAJumaK9g=G2F0pow9Eo=s1-nfcGe1=oq6CeBKv8X_EZeCyvmnw@mail.gmail.com>
References: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>
 <kursg500.c742c55a-7a19-49ff-80d5-cc268ba38f58@we.are.superhuman.com>
 <CAJumaK9g=G2F0pow9Eo=s1-nfcGe1=oq6CeBKv8X_EZeCyvmnw@mail.gmail.com>
Message-ID: <CAHYVw0x=NBL-Y7yTT+eX1JQww-R=p13VCxPxC5PGQCU6Qh6JJg@mail.gmail.com>

I agree with emily david and ed

Bringing readMaybe into prelude plus adding call stack info to read are the
Sane path forward to improving Haskell.

 Deprecating read, insofar as how ghc deprecation works, is a lotta pain
for no real hao.

On Thu, Oct 14, 2021 at 11:47 PM Edward Kmett <ekmett at gmail.com> wrote:

> A variant of this that I would support would be to bring readMaybe into
> Prelude from Text.Read for a good long time, and *then* to deprecate read.
> As it stands, read and the almost equally ugly readIO are the only Prelude
> facing ways for a user to really consume a Read instance, so losing read
> there is a heck of a blow to usability without a replacement being in place
> with an established pattern of usage.
>
> -Edward
>
> On Thu, Oct 14, 2021 at 11:16 PM Emily Pillmore <emilypi at cohomolo.gy>
> wrote:
>
>> NOPE.
>>
>>
>> On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita <fumiexcel at gmail.com>
>> wrote:
>>
>>> It is a partial function that does not provide a call stack, and it's
>>> very slow too.
>>>
>>> I propose deprecating Prelude.read <http://prelude.read/>. Adding
>>> deprecation should not break anything substantial because Hackage rejects
>>> -Werror (application code using -Werror is likely to experience a lot more
>>> breakage anyway, and I'd say it's their fault if it fails to build due to a
>>> use of read along with -Werror).
>>>
>>> Of course those who still want to use Prelude.read
>>> <http://prelude.read/> can totally ignore warnings. I believe this
>>> proposal is not that controversial.
>>>
>>> _______________________________________________
>>> 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/20211014/d6747536/attachment.html>

From fumiexcel at gmail.com  Fri Oct 15 04:27:41 2021
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Fri, 15 Oct 2021 13:27:41 +0900
Subject: Proposal: deprecate Prelude.read
In-Reply-To: <CAHYVw0x=NBL-Y7yTT+eX1JQww-R=p13VCxPxC5PGQCU6Qh6JJg@mail.gmail.com>
References: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>
 <kursg500.c742c55a-7a19-49ff-80d5-cc268ba38f58@we.are.superhuman.com>
 <CAJumaK9g=G2F0pow9Eo=s1-nfcGe1=oq6CeBKv8X_EZeCyvmnw@mail.gmail.com>
 <CAHYVw0x=NBL-Y7yTT+eX1JQww-R=p13VCxPxC5PGQCU6Qh6JJg@mail.gmail.com>
Message-ID: <CAATCwUnTGQkz52sVSfC8gB3Uhx66b0VcRbJvGGV83ZGnj1Fxdw@mail.gmail.com>

I'm not proposing to *remove* it; my suggestion is to attach a warning
perpetually (or like 20 years).
Without warnings, I think just adding readMaybe would have little incentive
to the ecosystem;
we can't expect people to eyeball the uses of read (highly generic name) in
their codebase.
We've broken a lot of code using fail simply because there was no warning
enabled by default.

To be clear I'm all for bringing readMaybe and readEither (I prefer the
either variant because of the Nothing blindness) into Prelude.
Once that happens, IMO DEPRECATE pragma should be added to encourage
switching to safer variants.

2021年10月15日(金) 12:53 Carter Schonwald <carter.schonwald at gmail.com>:

> I agree with emily david and ed
>
> Bringing readMaybe into prelude plus adding call stack info to read are
> the Sane path forward to improving Haskell.
>
>  Deprecating read, insofar as how ghc deprecation works, is a lotta pain
> for no real hao.
>
> On Thu, Oct 14, 2021 at 11:47 PM Edward Kmett <ekmett at gmail.com> wrote:
>
>> A variant of this that I would support would be to bring readMaybe into
>> Prelude from Text.Read for a good long time, and *then* to deprecate read.
>> As it stands, read and the almost equally ugly readIO are the only
>> Prelude facing ways for a user to really consume a Read instance, so
>> losing read there is a heck of a blow to usability without a replacement
>> being in place with an established pattern of usage.
>>
>> -Edward
>>
>> On Thu, Oct 14, 2021 at 11:16 PM Emily Pillmore <emilypi at cohomolo.gy>
>> wrote:
>>
>>> NOPE.
>>>
>>>
>>> On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita <fumiexcel at gmail.com>
>>> wrote:
>>>
>>>> It is a partial function that does not provide a call stack, and it's
>>>> very slow too.
>>>>
>>>> I propose deprecating Prelude.read <http://prelude.read/>. Adding
>>>> deprecation should not break anything substantial because Hackage rejects
>>>> -Werror (application code using -Werror is likely to experience a lot more
>>>> breakage anyway, and I'd say it's their fault if it fails to build due to a
>>>> use of read along with -Werror).
>>>>
>>>> Of course those who still want to use Prelude.read
>>>> <http://prelude.read/> can totally ignore warnings. I believe this
>>>> proposal is not that controversial.
>>>>
>>>> _______________________________________________
>>>> 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/20211015/ce5bf656/attachment.html>

From david.feuer at gmail.com  Fri Oct 15 04:37:32 2021
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 15 Oct 2021 00:37:32 -0400
Subject: Proposal: deprecate Prelude.read
In-Reply-To: <CAATCwUnTGQkz52sVSfC8gB3Uhx66b0VcRbJvGGV83ZGnj1Fxdw@mail.gmail.com>
References: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>
 <kursg500.c742c55a-7a19-49ff-80d5-cc268ba38f58@we.are.superhuman.com>
 <CAJumaK9g=G2F0pow9Eo=s1-nfcGe1=oq6CeBKv8X_EZeCyvmnw@mail.gmail.com>
 <CAHYVw0x=NBL-Y7yTT+eX1JQww-R=p13VCxPxC5PGQCU6Qh6JJg@mail.gmail.com>
 <CAATCwUnTGQkz52sVSfC8gB3Uhx66b0VcRbJvGGV83ZGnj1Fxdw@mail.gmail.com>
Message-ID: <CAMgWh9v5vXet2yJb8tTj6S-SsOhybdv-5AofPc988o4HyEsPag@mail.gmail.com>

readEither is kind of a lie. The Read parsing system has no real error
handling, so readEither just confuses people into thinking they're getting
a useful message when they're not.

On Fri, Oct 15, 2021 at 12:28 AM Fumiaki Kinoshita <fumiexcel at gmail.com>
wrote:

> I'm not proposing to *remove* it; my suggestion is to attach a warning
> perpetually (or like 20 years).
> Without warnings, I think just adding readMaybe would have little
> incentive to the ecosystem;
> we can't expect people to eyeball the uses of read (highly generic name)
> in their codebase.
> We've broken a lot of code using fail simply because there was no warning
> enabled by default.
>
> To be clear I'm all for bringing readMaybe and readEither (I prefer the
> either variant because of the Nothing blindness) into Prelude.
> Once that happens, IMO DEPRECATE pragma should be added to encourage
> switching to safer variants.
>
> 2021年10月15日(金) 12:53 Carter Schonwald <carter.schonwald at gmail.com>:
>
>> I agree with emily david and ed
>>
>> Bringing readMaybe into prelude plus adding call stack info to read are
>> the Sane path forward to improving Haskell.
>>
>>  Deprecating read, insofar as how ghc deprecation works, is a lotta pain
>> for no real hao.
>>
>> On Thu, Oct 14, 2021 at 11:47 PM Edward Kmett <ekmett at gmail.com> wrote:
>>
>>> A variant of this that I would support would be to bring readMaybe into
>>> Prelude from Text.Read for a good long time, and *then* to deprecate
>>> read. As it stands, read and the almost equally ugly readIO are the
>>> only Prelude facing ways for a user to really consume a Read instance,
>>> so losing read there is a heck of a blow to usability without a
>>> replacement being in place with an established pattern of usage.
>>>
>>> -Edward
>>>
>>> On Thu, Oct 14, 2021 at 11:16 PM Emily Pillmore <emilypi at cohomolo.gy>
>>> wrote:
>>>
>>>> NOPE.
>>>>
>>>>
>>>> On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita <fumiexcel at gmail.com
>>>> > wrote:
>>>>
>>>>> It is a partial function that does not provide a call stack, and it's
>>>>> very slow too.
>>>>>
>>>>> I propose deprecating Prelude.read <http://prelude.read/>. Adding
>>>>> deprecation should not break anything substantial because Hackage rejects
>>>>> -Werror (application code using -Werror is likely to experience a lot more
>>>>> breakage anyway, and I'd say it's their fault if it fails to build due to a
>>>>> use of read along with -Werror).
>>>>>
>>>>> Of course those who still want to use Prelude.read
>>>>> <http://prelude.read/> can totally ignore warnings. I believe this
>>>>> proposal is not that controversial.
>>>>>
>>>>> _______________________________________________
>>>>> 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/20211015/520bbddb/attachment.html>

From lemming at henning-thielemann.de  Fri Oct 15 08:05:50 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 15 Oct 2021 10:05:50 +0200 (CEST)
Subject: Proposal: deprecate Prelude.read
In-Reply-To: <CAMgWh9uTywg0WwAKNikkgBGg+3a3iDx3+0TWPYNtFgNjX_1Zmw@mail.gmail.com>
References: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>
 <CAMgWh9uTywg0WwAKNikkgBGg+3a3iDx3+0TWPYNtFgNjX_1Zmw@mail.gmail.com>
Message-ID: <e86176f6-21c-1dd3-4779-d49e63fbef49@henning-thielemann.de>


On Thu, 14 Oct 2021, David Feuer wrote:

> If it doesn't give a call stack, we can fix that. While I avoid using
> it myself, and I think it's much better to use (at least)
> Text.readMaybe, I'm not convinced that the breakage to existing
> educational material is worth the benefit of actually removing it.

One can use HLint to flag uses of 'read'.

From andreas.abel at ifi.lmu.de  Fri Oct 15 08:37:47 2021
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Fri, 15 Oct 2021 10:37:47 +0200
Subject: Proposal: deprecate Prelude.read
In-Reply-To: <e86176f6-21c-1dd3-4779-d49e63fbef49@henning-thielemann.de>
References: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>
 <CAMgWh9uTywg0WwAKNikkgBGg+3a3iDx3+0TWPYNtFgNjX_1Zmw@mail.gmail.com>
 <e86176f6-21c-1dd3-4779-d49e63fbef49@henning-thielemann.de>
Message-ID: <248dd984-1482-237e-06bb-072e6c1dcd07@ifi.lmu.de>

+1 to promoting `readMaybe`.

HLint could replace `read` by `fromMaybe undefined . readMaybe`. 
Partiality can be debugged better when it is in the application, rather 
than in the library.

On 2021-10-15 10:05, Henning Thielemann wrote:
> 
> On Thu, 14 Oct 2021, David Feuer wrote:
> 
>> If it doesn't give a call stack, we can fix that. While I avoid using
>> it myself, and I think it's much better to use (at least)
>> Text.readMaybe, I'm not convinced that the breakage to existing
>> educational material is worth the benefit of actually removing it.
> 
> One can use HLint to flag uses of 'read'.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From godzbanebane at gmail.com  Fri Oct 15 09:02:24 2021
From: godzbanebane at gmail.com (Georgi Lyubenov)
Date: Fri, 15 Oct 2021 12:02:24 +0300
Subject: Proposal: deprecate Prelude.read
In-Reply-To: <248dd984-1482-237e-06bb-072e6c1dcd07@ifi.lmu.de>
References: <CAATCwU=U1jOpdH8JPTFdgxyPhuv+KnkNvrou6h6Yd3c_GLoe3w@mail.gmail.com>
 <CAMgWh9uTywg0WwAKNikkgBGg+3a3iDx3+0TWPYNtFgNjX_1Zmw@mail.gmail.com>
 <e86176f6-21c-1dd3-4779-d49e63fbef49@henning-thielemann.de>
 <248dd984-1482-237e-06bb-072e6c1dcd07@ifi.lmu.de>
Message-ID: <CABT0e9qBsfWWvMypXk3m6EyTBPZ-=zXZJJ=+624uovBKAPzQuQ@mail.gmail.com>

I've started up this discussion over at the hlint issue tracker too:
https://github.com/ndmitchell/hlint/issues/1307

On Fri, Oct 15, 2021 at 11:39 AM Andreas Abel <andreas.abel at ifi.lmu.de>
wrote:

> +1 to promoting `readMaybe`.
>
> HLint could replace `read` by `fromMaybe undefined . readMaybe`.
> Partiality can be debugged better when it is in the application, rather
> than in the library.
>
> On 2021-10-15 10:05, Henning Thielemann wrote:
> >
> > On Thu, 14 Oct 2021, David Feuer wrote:
> >
> >> If it doesn't give a call stack, we can fix that. While I avoid using
> >> it myself, and I think it's much better to use (at least)
> >> Text.readMaybe, I'm not convinced that the breakage to existing
> >> educational material is worth the benefit of actually removing it.
> >
> > One can use HLint to flag uses of 'read'.
> > _______________________________________________
> > 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/20211015/733d9c47/attachment.html>

From mail at joachim-breitner.de  Wed Oct 20 14:39:21 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 20 Oct 2021 16:39:21 +0200
Subject: Make Eq type class single method
Message-ID: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>

Hi list,

I am revisiting some educational material about Haskell, and I stumble
over something that I keep stumbling over. I thought there was prior
discussion, but I couldn’t find it (operators hard hard to google for).

Why does Eq have a (/=) method?

Semantically, I don’t see a reason why an instance might want to behave
differently than the default method. And (in contrast to, say, Ord), I
would be surprised if there are noticable performance benefits to be
gained from implementing (/=) separately.

On the other hand, this is likely the first time a learner will
encounter a class with default methods, and it’s awkward to explain
“this mechanism is useful if you can have an optimized implementation,
but, eh, here it isn’t really possible”.

If we’d design the language now, would we include (/=) as a method?


If no: would it be worth removing it?

Yes, every change is annoying, but if are going to keep using Haskell
the next 30 days, it may pay off? And it might not be too bad: Remove
it from base, but teach GHC to not error out if an instance defines
(/=), but print a warning and otherwise ignore it. Libraries can remove
it if it is defined, which is a backwards-compatible change.

WDYT?
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Oct 20 14:43:20 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 20 Oct 2021 15:43:20 +0100
Subject: Make Eq type class single method
In-Reply-To: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
Message-ID: <20211020144320.GP22523@cloudinit-builder>

On Wed, Oct 20, 2021 at 04:39:21PM +0200, Joachim Breitner wrote:
> I am revisiting some educational material about Haskell, and I stumble
> over something that I keep stumbling over. I thought there was prior
> discussion, but I couldn’t find it (operators hard hard to google for).
> 
> Why does Eq have a (/=) method?

Perhaps sometimes it is easier to define (/=) and use the default
definition of (==) in terms of it?

From allbery.b at gmail.com  Wed Oct 20 14:48:51 2021
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 20 Oct 2021 10:48:51 -0400
Subject: Make Eq type class single method
In-Reply-To: <20211020144320.GP22523@cloudinit-builder>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <20211020144320.GP22523@cloudinit-builder>
Message-ID: <CAKFCL4Ut=5NGm2=oM+2p_aPRT0ao+S+Pp658te6CwhQsO-bWjg@mail.gmail.com>

>
> I'm finding it hard to think of a case where (/=) would be any easier to
> define than (==).


On Wed, Oct 20, 2021 at 10:43 AM Tom Ellis <
tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:

> On Wed, Oct 20, 2021 at 04:39:21PM +0200, Joachim Breitner wrote:
> > I am revisiting some educational material about Haskell, and I stumble
> > over something that I keep stumbling over. I thought there was prior
> > discussion, but I couldn’t find it (operators hard hard to google for).
> >
> > Why does Eq have a (/=) method?
>
> Perhaps sometimes it is easier to define (/=) and use the default
> definition of (==) in terms of it?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211020/baa734d7/attachment.html>

From mail at joachim-breitner.de  Wed Oct 20 14:55:15 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 20 Oct 2021 16:55:15 +0200
Subject: Make Eq type class single method
In-Reply-To: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
Message-ID: <b0eb0ba68b7ccfd8c1ef99aab0f49b0f09dd1f21.camel@joachim-breitner.de>

Hi,

oh, and I completely forgot to add:

Am Mittwoch, dem 20.10.2021 um 16:39 +0200 schrieb Joachim Breitner:
> If no: would it be worth removing it?
> 
> Yes, every change is annoying, but if are going to keep using Haskell
> the next 30 days, it may pay off? And it might not be too bad: Remove
> it from base, but teach GHC to not error out if an instance defines
> (/=), but print a warning and otherwise ignore it. Libraries can remove
> it if it is defined, which is a backwards-compatible change.

And an (important?) benefit would be that now Eq would then be a
single-method class, which are compiled by GHC more efficiently – they
essentially _are_ the (==) function, not a tuple of both methods. For
something as low-level as (==), this might be measurable…

Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From jens.blanck at gmail.com  Wed Oct 20 15:05:04 2021
From: jens.blanck at gmail.com (Jens Blanck)
Date: Wed, 20 Oct 2021 16:05:04 +0100
Subject: Make Eq type class single method
In-Reply-To: <b0eb0ba68b7ccfd8c1ef99aab0f49b0f09dd1f21.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <b0eb0ba68b7ccfd8c1ef99aab0f49b0f09dd1f21.camel@joachim-breitner.de>
Message-ID: <CAKH40QP3ebXyjQK+vRKyiU6u9OoBPtGL+M_Frqo=G_a3gaVgsg@mail.gmail.com>

Hi,

Sometimes, /= is semidecidable and == only cosemidecidable. E.g. Exact Real
Arithmetic.

Best,
Jens

On Wed, 20 Oct 2021 at 15:56, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> oh, and I completely forgot to add:
>
> Am Mittwoch, dem 20.10.2021 um 16:39 +0200 schrieb Joachim Breitner:
> > If no: would it be worth removing it?
> >
> > Yes, every change is annoying, but if are going to keep using Haskell
> > the next 30 days, it may pay off? And it might not be too bad: Remove
> > it from base, but teach GHC to not error out if an instance defines
> > (/=), but print a warning and otherwise ignore it. Libraries can remove
> > it if it is defined, which is a backwards-compatible change.
>
> And an (important?) benefit would be that now Eq would then be a
> single-method class, which are compiled by GHC more efficiently – they
> essentially _are_ the (==) function, not a tuple of both methods. For
> something as low-level as (==), this might be measurable…
>
> Cheers,
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> 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/20211020/04ee506e/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Oct 20 15:08:55 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 20 Oct 2021 16:08:55 +0100
Subject: Make Eq type class single method
In-Reply-To: <b0eb0ba68b7ccfd8c1ef99aab0f49b0f09dd1f21.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <b0eb0ba68b7ccfd8c1ef99aab0f49b0f09dd1f21.camel@joachim-breitner.de>
Message-ID: <20211020150855.GQ22523@cloudinit-builder>

On Wed, Oct 20, 2021 at 04:55:15PM +0200, Joachim Breitner wrote:
> Am Mittwoch, dem 20.10.2021 um 16:39 +0200 schrieb Joachim Breitner:
> > If no: would it be worth removing it?
> > 
> > Yes, every change is annoying, but if are going to keep using Haskell
> > the next 30 days, it may pay off? And it might not be too bad: Remove
> > it from base, but teach GHC to not error out if an instance defines
> > (/=), but print a warning and otherwise ignore it. Libraries can remove
> > it if it is defined, which is a backwards-compatible change.
> 
> And an (important?) benefit would be that now Eq would then be a
> single-method class, which are compiled by GHC more efficiently – they
> essentially _are_ the (==) function, not a tuple of both methods. For
> something as low-level as (==), this might be measurable…

Since (/=) is an Eq class method it can be implemented on (Int, Int)
as

  (x1, x2) /= (y1, y2) = (x1 /= y1) || (x2 /= y2)

If it were not a class method it would have to be implemented as,
after inlining

  (x1, x2) /= (y1, y2) = not ((x1 == y1) && (x2 == y2))

Might not the latter be less efficient, because of the extra `not`?

Tom

From ietf-dane at dukhovni.org  Wed Oct 20 15:15:01 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Wed, 20 Oct 2021 11:15:01 -0400
Subject: Make Eq type class single method
In-Reply-To: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
Message-ID: <YXAydaosAuHWmVAS@straasha.imrryr.org>

On Wed, Oct 20, 2021 at 04:39:21PM +0200, Joachim Breitner wrote:

> I am revisiting some educational material about Haskell, and I stumble
> over something that I keep stumbling over. I thought there was prior
> discussion, but I couldn’t find it (operators hard hard to google for).
> 
> Why does Eq have a (/=) method?

For primitive types CPUs often have both '==' and '/=' instructions,
and so a direct call to `(/=)` may be more efficient than calling
`(not .) . (==)`.  The base package defines:

    instance Eq Int8 where
        (==) = eqInt8
        (/=) = neInt8
    instance Eq Int16 where
        (==) = eqInt16
        (/=) = neInt16
    instance Eq Int32 where
        (==) = eqInt32
        (/=) = neInt32
    instance Eq Int64 where
        (==) = eqInt64
        (/=) = neInt64

    instance Eq Word8 where
        (==) = eqWord8
        (/=) = neWord8
    instance Eq Word16 where
        (==) = eqWord16
        (/=) = neWord16
    instance Eq Word32 where
        (==) = eqWord32
        (/=) = neWord32
    instance Eq Word64 where
        (==) = eqWord64
        (/=) = neWord64

There are also various cases involving equality/inequaility on
getUnique, ...

    compiler/GHC/Core/Coercion/Axiom.hs:instance Eq (CoAxiom br) where
    compiler/GHC/Core/Coercion/Axiom.hs-    a == b = getUnique a == getUnique b
    compiler/GHC/Core/Coercion/Axiom.hs-    a /= b = getUnique a /= getUnique b

    compiler/GHC/Core/Class.hs:instance Eq Class where
    compiler/GHC/Core/Class.hs-    c1 == c2 = classKey c1 == classKey c2
    compiler/GHC/Core/Class.hs-    c1 /= c2 = classKey c1 /= classKey c2

I don't know whether optimisations to use direct CPU instructions pay
their way relative to the cost of larger Eq dictionaries in other
contexts, but this seems to be at least a plausible reason.

-- 
    Viktor.

From andreas.abel at ifi.lmu.de  Wed Oct 20 15:15:16 2021
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Wed, 20 Oct 2021 17:15:16 +0200
Subject: Make Eq type class single method
In-Reply-To: <CAKFCL4Ut=5NGm2=oM+2p_aPRT0ao+S+Pp658te6CwhQsO-bWjg@mail.gmail.com>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <20211020144320.GP22523@cloudinit-builder>
 <CAKFCL4Ut=5NGm2=oM+2p_aPRT0ao+S+Pp658te6CwhQsO-bWjg@mail.gmail.com>
Message-ID: <bf8ddcef-e067-9605-9a16-2b976ce13bc3@ifi.lmu.de>

As in so many other cases, documenting the design decisions (that lead 
to (/=) in Eq) would have helped [even for the initial reflection on 
this design].

I see that in another thread there are reasons brought forward in favor 
of (/=).  So if the outcome of this discussion is "no change", the 
reasons should be added to the documentation of the Eq class.

--Andreas

On 2021-10-20 16:48, Brandon Allbery wrote:
>     I'm finding it hard to think of a case where (/=) would be any
>     easier to define than (==).
> 
> 
> On Wed, Oct 20, 2021 at 10:43 AM Tom Ellis 
> <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk 
> <mailto:tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>> wrote:
> 
>     On Wed, Oct 20, 2021 at 04:39:21PM +0200, Joachim Breitner wrote:
>      > I am revisiting some educational material about Haskell, and I
>     stumble
>      > over something that I keep stumbling over. I thought there was prior
>      > discussion, but I couldn’t find it (operators hard hard to google
>     for).
>      >
>      > Why does Eq have a (/=) method?
> 
>     Perhaps sometimes it is easier to define (/=) and use the default
>     definition of (==) in terms of it?


From mail at joachim-breitner.de  Wed Oct 20 15:25:22 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 20 Oct 2021 17:25:22 +0200
Subject: Make Eq type class single method
In-Reply-To: <20211020150855.GQ22523@cloudinit-builder>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <b0eb0ba68b7ccfd8c1ef99aab0f49b0f09dd1f21.camel@joachim-breitner.de>
 <20211020150855.GQ22523@cloudinit-builder>
Message-ID: <38243b480069a483b59a51e242e391a1c85c8201.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 20.10.2021 um 16:08 +0100 schrieb Tom Ellis:
> Since (/=) is an Eq class method it can be implemented on (Int, Int)
> as
> 
>   (x1, x2) /= (y1, y2) = (x1 /= y1) || (x2 /= y2)
> 
> If it were not a class method it would have to be implemented as,
> after inlining
> 
>   (x1, x2) /= (y1, y2) = not ((x1 == y1) && (x2 == y2))
> 
> Might not the latter be less efficient, because of the extra `not`?

maybe. I think I’ll simply try it out, and see if for example GHC
itself speeds up if (/=) is not a class method.

Note that if the inner Eq is using the default implementation, then
there will be _two_ not there.

I’d expect that not will quickly inline, and the cost of an inlined not
might be small compared to the cost of projecting (/=) out of the class
dictionary (in polymorphic code). And in other cases, the (/=) might
inline and the not might be fused with the surrounding code via case-
of-case. 

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Wed Oct 20 15:26:05 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 20 Oct 2021 17:26:05 +0200
Subject: Make Eq type class single method
In-Reply-To: <CAKH40QP3ebXyjQK+vRKyiU6u9OoBPtGL+M_Frqo=G_a3gaVgsg@mail.gmail.com>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <b0eb0ba68b7ccfd8c1ef99aab0f49b0f09dd1f21.camel@joachim-breitner.de>
 <CAKH40QP3ebXyjQK+vRKyiU6u9OoBPtGL+M_Frqo=G_a3gaVgsg@mail.gmail.com>
Message-ID: <8e3464f6023f269afa1c64554750674804f9358a.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 20.10.2021 um 16:05 +0100 schrieb Jens Blanck:
> Sometimes, /= is semidecidable and == only cosemidecidable. E.g.
> Exact Real Arithmetic.

does that reasoning apply here? (/=) still returns True or False, so
they are still both deciding the same question.

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From oleg.grenrus at iki.fi  Wed Oct 20 16:49:52 2021
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Wed, 20 Oct 2021 19:49:52 +0300
Subject: Make Eq type class single method
In-Reply-To: <YXAydaosAuHWmVAS@straasha.imrryr.org>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
Message-ID: <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>

The changes needed to compile GHC itself are small-ish, and indeed include
the primitive types and few others.

text library needs change as well, which is unfortunate

 import Prelude (Char, Bool(..), Int, Maybe(..), String,
-                Eq(..), Ord(..), Ordering(..), (++),
+                Eq(..), (/=), Ord(..), Ordering(..), (++),
                 Read(..),

It's somewhat common to import things explicitly from Prelude,
I do this often when writing something with wide base support,
and which uses the same names as in Prelude.
But this is simple change to do downstream.

I attach the patches for ghc, containers and text.
I encourage someone (Joachim?) to run the nofib suite.

Also, we coudl add builtin rewrite rules, rewriting not (eqInt8 x y)
to neInt8 x y if some benchmarks show that it would be beneficial.

- Oleg

On 20.10.2021 18.15, Viktor Dukhovni wrote:
> On Wed, Oct 20, 2021 at 04:39:21PM +0200, Joachim Breitner wrote:
>
>> I am revisiting some educational material about Haskell, and I stumble
>> over something that I keep stumbling over. I thought there was prior
>> discussion, but I couldn’t find it (operators hard hard to google for).
>>
>> Why does Eq have a (/=) method?
> For primitive types CPUs often have both '==' and '/=' instructions,
> and so a direct call to `(/=)` may be more efficient than calling
> `(not .) . (==)`.  The base package defines:
>
>     instance Eq Int8 where
>         (==) = eqInt8
>         (/=) = neInt8
>     instance Eq Int16 where
>         (==) = eqInt16
>         (/=) = neInt16
>     instance Eq Int32 where
>         (==) = eqInt32
>         (/=) = neInt32
>     instance Eq Int64 where
>         (==) = eqInt64
>         (/=) = neInt64
>
>     instance Eq Word8 where
>         (==) = eqWord8
>         (/=) = neWord8
>     instance Eq Word16 where
>         (==) = eqWord16
>         (/=) = neWord16
>     instance Eq Word32 where
>         (==) = eqWord32
>         (/=) = neWord32
>     instance Eq Word64 where
>         (==) = eqWord64
>         (/=) = neWord64
>
> There are also various cases involving equality/inequaility on
> getUnique, ...
>
>     compiler/GHC/Core/Coercion/Axiom.hs:instance Eq (CoAxiom br) where
>     compiler/GHC/Core/Coercion/Axiom.hs-    a == b = getUnique a == getUnique b
>     compiler/GHC/Core/Coercion/Axiom.hs-    a /= b = getUnique a /= getUnique b
>
>     compiler/GHC/Core/Class.hs:instance Eq Class where
>     compiler/GHC/Core/Class.hs-    c1 == c2 = classKey c1 == classKey c2
>     compiler/GHC/Core/Class.hs-    c1 /= c2 = classKey c1 /= classKey c2
>
> I don't know whether optimisations to use direct CPU instructions pay
> their way relative to the cost of larger Eq dictionaries in other
> contexts, but this seems to be at least a plausible reason.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: containers.diff
Type: text/x-patch
Size: 1037 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211020/1d3a89f4/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: text.diff
Type: text/x-patch
Size: 483 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211020/1d3a89f4/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ghc.diff
Type: text/x-patch
Size: 10719 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211020/1d3a89f4/attachment-0002.bin>

From svenpanne at gmail.com  Wed Oct 20 16:52:19 2021
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 20 Oct 2021 18:52:19 +0200
Subject: Make Eq type class single method
In-Reply-To: <YXAydaosAuHWmVAS@straasha.imrryr.org>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
Message-ID: <CANBN=mt=uvd0C7xRYHf5LiSCCj+r_5LZHvSM63+iRm_R85q=2Q@mail.gmail.com>

Am Mi., 20. Okt. 2021 um 17:17 Uhr schrieb Viktor Dukhovni <
ietf-dane at dukhovni.org>:

> For primitive types CPUs often have both '==' and '/=' instructions,
> and so a direct call to `(/=)` may be more efficient than calling
> `(not .) . (==)`.  [...]


For every native code generator which is worth its salt, this shouldn't
make a difference at all. Swapping the "polarity" of a condition is an
extremely common transformation, which can be used for many reasons. And
even if you don't have anything sophisticated, a simple peephole optimizer
can get rid of the negation operation. And even if all that doesn't help:
Perhaps the negation + condition are fused together in the microcode
operations, depending on your CPU.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211020/5a01b5e5/attachment.html>

From david.feuer at gmail.com  Wed Oct 20 16:53:00 2021
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 20 Oct 2021 12:53:00 -0400
Subject: Make Eq type class single method
In-Reply-To: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
Message-ID: <CAMgWh9s-bKzANMbGq07WcEK7bq_+otQKK5666y-c+fhv1D6Hgw@mail.gmail.com>

This sounds good to me. Having (/=) be a method has always seemed like a
bit of a wart, since it's hard to imagine either a reason to define it
explicitly or a reason to want it in a dictionary.

On Wed, Oct 20, 2021, 10:40 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi list,
>
> I am revisiting some educational material about Haskell, and I stumble
> over something that I keep stumbling over. I thought there was prior
> discussion, but I couldn’t find it (operators hard hard to google for).
>
> Why does Eq have a (/=) method?
>
> Semantically, I don’t see a reason why an instance might want to behave
> differently than the default method. And (in contrast to, say, Ord), I
> would be surprised if there are noticable performance benefits to be
> gained from implementing (/=) separately.
>
> On the other hand, this is likely the first time a learner will
> encounter a class with default methods, and it’s awkward to explain
> “this mechanism is useful if you can have an optimized implementation,
> but, eh, here it isn’t really possible”.
>
> If we’d design the language now, would we include (/=) as a method?
>
>
> If no: would it be worth removing it?
>
> Yes, every change is annoying, but if are going to keep using Haskell
> the next 30 days, it may pay off? And it might not be too bad: Remove
> it from base, but teach GHC to not error out if an instance defines
> (/=), but print a warning and otherwise ignore it. Libraries can remove
> it if it is defined, which is a backwards-compatible change.
>
> WDYT?
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> 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/20211020/7422cd7a/attachment.html>

From svenpanne at gmail.com  Wed Oct 20 16:55:11 2021
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 20 Oct 2021 18:55:11 +0200
Subject: Make Eq type class single method
In-Reply-To: <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
Message-ID: <CANBN=ms_TifrSe2Y=+Q011k8Ve2uFxz8v5NC870sNP2OeRc+Wg@mail.gmail.com>

Am Mi., 20. Okt. 2021 um 18:51 Uhr schrieb Oleg Grenrus <oleg.grenrus at iki.fi
>:

> [...] Also, we coudl add builtin rewrite rules, rewriting not (eqInt8 x y)
> to neInt8 x y if some benchmarks show that it would be beneficial.


Hopefully such peephole optimizations are done much more generally further
down the compilation pipeline, otherwise we will have more serious
performance problems than the removal of (/=) from Eq. ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211020/4c1ec914/attachment.html>

From oleg.grenrus at iki.fi  Wed Oct 20 17:11:34 2021
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Wed, 20 Oct 2021 20:11:34 +0300
Subject: Make Eq type class single method
In-Reply-To: <CANBN=ms_TifrSe2Y=+Q011k8Ve2uFxz8v5NC870sNP2OeRc+Wg@mail.gmail.com>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <CANBN=ms_TifrSe2Y=+Q011k8Ve2uFxz8v5NC870sNP2OeRc+Wg@mail.gmail.com>
Message-ID: <51766c59-43b8-9017-0c7e-fa8899e77895@iki.fi>

It might be they are not required.

In example like

{-# OPTIONS_GHC -ddump-simpl -dsuppress-all #-}

import System.Environment
import Data.Word

main :: IO ()
main = do
    [x',y'] <- getArgs
    let x, y :: Word
        x = read x'
        y = read y'

    print (not (x == y))

GHC is smart enough to just swap the branches, relevant optimized core
looks like

case x_a4Tc of { W# x2_a3Wb ->
case x1_X4Ua of { W# y_a3Wf ->
case eqWord# x2_a3Wb y_a3Wf of {
  __DEFAULT -> $fShowBool2;
  1# -> $fShowBool4
}
}
};

where `$fShowBool*` are (probably, I haven't checked) printing True or
False.

I.e. expressions which are "case (not x) of True -> ..., False -> ..."
optimize well,
early enough. (IIRC that's the example used for case-of-case optimization).

- Oleg

On 20.10.2021 19.55, Sven Panne wrote:
> Am Mi., 20. Okt. 2021 um 18:51 Uhr schrieb Oleg Grenrus
> <oleg.grenrus at iki.fi <mailto:oleg.grenrus at iki.fi>>:
>
>     [...] Also, we coudl add builtin rewrite rules, rewriting not
>     (eqInt8 x y)
>     to neInt8 x y if some benchmarks show that it would be beneficial.
>
>
> Hopefully such peephole optimizations are done much more generally
> further down the compilation pipeline, otherwise we will have more
> serious performance problems than the removal of (/=) from Eq. ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211020/d61ebbb4/attachment.html>

From ekmett at gmail.com  Wed Oct 20 18:57:05 2021
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 20 Oct 2021 14:57:05 -0400
Subject: Make Eq type class single method
In-Reply-To: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
Message-ID: <CAJumaK8nbomR+n=xR1gNq7w6Erjcry_9r320LJy7n_Jz4CRUpw@mail.gmail.com>

Interestingly, I'd always assumed the answer was that all comparison
functions should return False for NaN, and mentally just assumed that would
include (/=). I never actually tested if (/=) returned False, but
apparently this isn't the case.

Prelude> (0/0) == (0/0)
False

Prelude> (0/0) /= (0/0)
True

So I can come up with no reason for (/=) to be included in the class today,
other than historical precedent based on the language report.

All the "GHC can optimize it better" things should be something that should
be able to be knocked out with relatively little fanfare, and are likely
dominated by the cost of wrapping up the method in a dictionary in the
cases where it doesn't fully inline away.

-Edward

On Wed, Oct 20, 2021 at 10:40 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi list,
>
> I am revisiting some educational material about Haskell, and I stumble
> over something that I keep stumbling over. I thought there was prior
> discussion, but I couldn’t find it (operators hard hard to google for).
>
> Why does Eq have a (/=) method?
>
> Semantically, I don’t see a reason why an instance might want to behave
> differently than the default method. And (in contrast to, say, Ord), I
> would be surprised if there are noticable performance benefits to be
> gained from implementing (/=) separately.
>
> On the other hand, this is likely the first time a learner will
> encounter a class with default methods, and it’s awkward to explain
> “this mechanism is useful if you can have an optimized implementation,
> but, eh, here it isn’t really possible”.
>
> If we’d design the language now, would we include (/=) as a method?
>
>
> If no: would it be worth removing it?
>
> Yes, every change is annoying, but if are going to keep using Haskell
> the next 30 days, it may pay off? And it might not be too bad: Remove
> it from base, but teach GHC to not error out if an instance defines
> (/=), but print a warning and otherwise ignore it. Libraries can remove
> it if it is defined, which is a backwards-compatible change.
>
> WDYT?
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> 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/20211020/315add01/attachment.html>

From svenpanne at gmail.com  Wed Oct 20 19:30:19 2021
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 20 Oct 2021 21:30:19 +0200
Subject: Make Eq type class single method
In-Reply-To: <CAJumaK8nbomR+n=xR1gNq7w6Erjcry_9r320LJy7n_Jz4CRUpw@mail.gmail.com>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <CAJumaK8nbomR+n=xR1gNq7w6Erjcry_9r320LJy7n_Jz4CRUpw@mail.gmail.com>
Message-ID: <CANBN=msyYyz0_peVcFDLGeczqoJ-BY6Vqz9TvrANkBO0kscKQA@mail.gmail.com>

Am Mi., 20. Okt. 2021 um 20:57 Uhr schrieb Edward Kmett <ekmett at gmail.com>:

> Interestingly, I'd always assumed the answer was that all comparison
> functions should return False for NaN, and mentally just assumed that would
> include (/=). I never actually tested if (/=) returned False, but
> apparently this isn't the case. [...]
>

NaN is the only value where the result of "x == x" is *swapped*. The
reasoning behind this by Kahan himself in e.g.
https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF:

Were there no way to get rid of NaNs, they would be as useless as
> Indefinites on CRAYs; as soon as one were encountered, computation would be
> best stopped rather than continued for an indefinite time to an Indefinite
> conclusion. That is why some operations upon NaNs must deliver non-NaN
> results. Which operations? Disagreements about some of them are inevitable,
> but that grants no license to resolve the disagreements by making arbitrary
> choices. Every real ( not logical ) function that produces the same
> floating-point result for all finite and infinite numerical values of an
> argument should yield the same result when that argument is NaN. ( Recall
> hypot above.) The exceptions are C predicates “ x == x ” and “ x != x ”,
> which are respectively 1 and 0 for every infinite or finite number x but
> reverse if x is Not a Number ( NaN ); these provide the only simple
> unexceptional distinction between NaNs and numbers in languages that lack a
> word for NaN and a predicate IsNaN(x). Overoptimizing compilers that
> substitute 1 for x == x violate IEEE 754.


IEEE 754 Wonderland... :-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211020/1844b067/attachment-0001.html>

From mail at joachim-breitner.de  Wed Oct 20 20:28:30 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 20 Oct 2021 22:28:30 +0200
Subject: Make Eq type class single method
In-Reply-To: <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
Message-ID: <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>

Hi,

parallel work… should have linked to
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6793
earlier. But yes, it is rather simple to make that change.

Am Mittwoch, dem 20.10.2021 um 19:49 +0300 schrieb Oleg Grenrus:
> I attach the patches for ghc, containers and text.
> I encourage someone (Joachim?) to run the nofib suite.

nofib might be too specialized; I think “ghc compiling Cabal” is a good
benchmark. I’ll do that eventually, if GHC’s CI doesn’t do that already
for me (I’ll ask Ben what kind of infrastructure we have for that –
doing it manually and correctly is tedious and error-prone), maybe
tomorrow. 

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From carter.schonwald at gmail.com  Thu Oct 21 14:18:51 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 21 Oct 2021 10:18:51 -0400
Subject: Make Eq type class single method
In-Reply-To: <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
Message-ID: <CAHYVw0xKm899jrzxo6K2NPmKSvuF=OoMSddG5c2QA8H=iZxEdQ@mail.gmail.com>

So one thing I’d like to highlight, that I don’t know if we could bake into
ghc safely and might not be relevant here is:

At least in some cases, implementations of EQ may use
“reallyUnsafePtrEquality#”, as a never false positive check that two heap
values are the same heap object. Naively this seems like it’s probably
orthogonal to the matter of Eq being a single or double method type class,
but I figure it’s worth asking out loud

On Wed, Oct 20, 2021 at 4:29 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> parallel work… should have linked to
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6793
> earlier. But yes, it is rather simple to make that change.
>
> Am Mittwoch, dem 20.10.2021 um 19:49 +0300 schrieb Oleg Grenrus:
> > I attach the patches for ghc, containers and text.
> > I encourage someone (Joachim?) to run the nofib suite.
>
> nofib might be too specialized; I think “ghc compiling Cabal” is a good
> benchmark. I’ll do that eventually, if GHC’s CI doesn’t do that already
> for me (I’ll ask Ben what kind of infrastructure we have for that –
> doing it manually and correctly is tedious and error-prone), maybe
> tomorrow.
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> 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/20211021/7c77e389/attachment.html>

From david.feuer at gmail.com  Thu Oct 21 15:12:48 2021
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 21 Oct 2021 11:12:48 -0400
Subject: Make Eq type class single method
In-Reply-To: <CAHYVw0xKm899jrzxo6K2NPmKSvuF=OoMSddG5c2QA8H=iZxEdQ@mail.gmail.com>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <CAHYVw0xKm899jrzxo6K2NPmKSvuF=OoMSddG5c2QA8H=iZxEdQ@mail.gmail.com>
Message-ID: <CAMgWh9u-ywOU3LVFJsuQ_Dsjf9LP3g1LeusbMor21TypcL3n9A@mail.gmail.com>

Not relevant. One question i have though: in the case of primitive types,
can switching from a primitive `/=` to one based on `==` change the order
of branches and thereby affect performance for better or worse?

On Thu, Oct 21, 2021, 10:19 AM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> So one thing I’d like to highlight, that I don’t know if we could bake
> into ghc safely and might not be relevant here is:
>
> At least in some cases, implementations of EQ may use
> “reallyUnsafePtrEquality#”, as a never false positive check that two heap
> values are the same heap object. Naively this seems like it’s probably
> orthogonal to the matter of Eq being a single or double method type class,
> but I figure it’s worth asking out loud
>
> On Wed, Oct 20, 2021 at 4:29 PM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> parallel work… should have linked to
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6793
>> earlier. But yes, it is rather simple to make that change.
>>
>> Am Mittwoch, dem 20.10.2021 um 19:49 +0300 schrieb Oleg Grenrus:
>> > I attach the patches for ghc, containers and text.
>> > I encourage someone (Joachim?) to run the nofib suite.
>>
>> nofib might be too specialized; I think “ghc compiling Cabal” is a good
>> benchmark. I’ll do that eventually, if GHC’s CI doesn’t do that already
>> for me (I’ll ask Ben what kind of infrastructure we have for that –
>> doing it manually and correctly is tedious and error-prone), maybe
>> tomorrow.
>>
>> Cheers,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> 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/20211021/6c6de371/attachment.html>

From allbery.b at gmail.com  Thu Oct 21 15:19:09 2021
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 21 Oct 2021 11:19:09 -0400
Subject: Make Eq type class single method
In-Reply-To: <CAMgWh9u-ywOU3LVFJsuQ_Dsjf9LP3g1LeusbMor21TypcL3n9A@mail.gmail.com>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <CAHYVw0xKm899jrzxo6K2NPmKSvuF=OoMSddG5c2QA8H=iZxEdQ@mail.gmail.com>
 <CAMgWh9u-ywOU3LVFJsuQ_Dsjf9LP3g1LeusbMor21TypcL3n9A@mail.gmail.com>
Message-ID: <CAKFCL4WcvWo6NW9p2+-+wyaD8ug5=7dcW1Hfv_mA4j6F2wP-kQ@mail.gmail.com>

Wasn't it already shown that ghc already swaps the order of branches to
match?

On Thu, Oct 21, 2021 at 11:13 AM David Feuer <david.feuer at gmail.com> wrote:

> Not relevant. One question i have though: in the case of primitive types,
> can switching from a primitive `/=` to one based on `==` change the order
> of branches and thereby affect performance for better or worse?
>
> On Thu, Oct 21, 2021, 10:19 AM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> So one thing I’d like to highlight, that I don’t know if we could bake
>> into ghc safely and might not be relevant here is:
>>
>> At least in some cases, implementations of EQ may use
>> “reallyUnsafePtrEquality#”, as a never false positive check that two heap
>> values are the same heap object. Naively this seems like it’s probably
>> orthogonal to the matter of Eq being a single or double method type class,
>> but I figure it’s worth asking out loud
>>
>> On Wed, Oct 20, 2021 at 4:29 PM Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>>> Hi,
>>>
>>> parallel work… should have linked to
>>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6793
>>> earlier. But yes, it is rather simple to make that change.
>>>
>>> Am Mittwoch, dem 20.10.2021 um 19:49 +0300 schrieb Oleg Grenrus:
>>> > I attach the patches for ghc, containers and text.
>>> > I encourage someone (Joachim?) to run the nofib suite.
>>>
>>> nofib might be too specialized; I think “ghc compiling Cabal” is a good
>>> benchmark. I’ll do that eventually, if GHC’s CI doesn’t do that already
>>> for me (I’ll ask Ben what kind of infrastructure we have for that –
>>> doing it manually and correctly is tedious and error-prone), maybe
>>> tomorrow.
>>>
>>> Cheers,
>>> Joachim
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>>
>>>
>>> _______________________________________________
>>> 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
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211021/bf441349/attachment.html>

From mail at joachim-breitner.de  Fri Oct 22 10:11:24 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 22 Oct 2021 12:11:24 +0200
Subject: Make Eq type class single method
In-Reply-To: <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
Message-ID: <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 20.10.2021 um 22:28 +0200 schrieb Joachim Breitner:
> nofib might be too specialized; I think “ghc compiling Cabal” is a good
> benchmark. I’ll do that eventually, if GHC’s CI doesn’t do that already
> for me (I’ll ask Ben what kind of infrastructure we have for that –
> doing it manually and correctly is tedious and error-prone), maybe
> tomorrow. 

Thanks for Mortiz Angerman for giving me access to a quiet machine.
Here my crude setup to measure the time it takes GHC to compiler Cabal:

$ for branch in ghc ghc-single-method-eq; do echo $branch; cd $branch; for i in 1 2 3 4 5; do /run/current-system/sw/bin/time _build/stage1/bin/ghc -hidir tmp -odir tmp -fforce-recomp +RTS -t -ttmp/ghc.log -RTS -ilibraries/Cabal/Cabal/src -XNoPolyKinds Distribution.Simple -O2 -v0; done; cd ..; done
ghc
128.67user 2.03system 2:10.60elapsed
128.92user 2.00system 2:10.76elapsed
129.36user 2.07system 2:11.30elapsed
128.83user 2.02system 2:10.71elapsed
128.76user 2.13system 2:10.71elapsed
ghc-single-method-eq
128.14user 2.04system 2:10.02elapsed
128.14user 2.02system 2:10.00elapsed
127.68user 2.12system 2:09.64elapsed
128.10user 2.05system 2:10.02elapsed
129.23user 1.95system 2:11.05elapsed

I guess that means no significant improvement…

(Such measurements always leave me wondering if I draw the right
conclusions, and my setup is good. I crave for some expertly-setup
measurement system where I don't have to worry about that, and I simply
get a result.)

Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Mon Oct 25 09:04:50 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 25 Oct 2021 11:04:50 +0200
Subject: Proposal: Make Eq type class single method
In-Reply-To: <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
Message-ID: <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>

Hi,

current status of this train of thought:

* Most people here were sympathetic about the removal of (/=) from Eq.

* It would break a bit of code, but with an easy and backward-
  compatible fix.

* The GHC implementation is straight forward:
  https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6793

* There is _no_ measurable performance benefit in real-world-code.
  A few of GHC’s perf regression tests benefit slightly:

    T12234(optasm) ghc/alloc    57633544.0    55409592.0  -3.9% GOOD
    T18304(normal) ghc/alloc    87566616.0    83503296.0  -4.6% GOOD
      T783(normal) ghc/alloc   389240752.0   377482584.0  -3.0% GOOD
     T1969(normal) ghc/max    19869024.0    19071720.0  -4.0% 
    T11545(normal) ghc/max    35580832.0    33828936.0  -4.9% 

* There is a problem with rules matching on class ops of single method 
  classes: https://gitlab.haskell.org/ghc/ghc/-/issues/20535
  I consider this a GHC bug that needs to be fixed anyways, so let’s
  assume for now it will be fixed one way or another before Eq becomes
  a single method class.

With this, I’d like to formally bring this change before the CLC, and
ask for its support for (or explicit rejection of) this change.

Cheers,
Joachim
  

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Mon Oct 25 09:14:37 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Mon, 25 Oct 2021 10:14:37 +0100
Subject: Proposal: Make Eq type class single method
In-Reply-To: <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
Message-ID: <20211025091437.GH9145@cloudinit-builder>

On Mon, Oct 25, 2021 at 11:04:50AM +0200, Joachim Breitner wrote:
> current status of this train of thought:
> 
> * Most people here were sympathetic about the removal of (/=) from Eq.
> 
> * It would break a bit of code, but with an easy and backward-
>   compatible fix.
> 
> * The GHC implementation is straight forward:
>   https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6793
> 
> * There is _no_ measurable performance benefit in real-world-code.
>   A few of GHC’s perf regression tests benefit slightly:
> 
>     T12234(optasm) ghc/alloc    57633544.0    55409592.0  -3.9% GOOD
>     T18304(normal) ghc/alloc    87566616.0    83503296.0  -4.6% GOOD
>       T783(normal) ghc/alloc   389240752.0   377482584.0  -3.0% GOOD
>      T1969(normal) ghc/max    19869024.0    19071720.0  -4.0% 
>     T11545(normal) ghc/max    35580832.0    33828936.0  -4.9% 
> 
> * There is a problem with rules matching on class ops of single method 
>   classes: https://gitlab.haskell.org/ghc/ghc/-/issues/20535
>   I consider this a GHC bug that needs to be fixed anyways, so let’s
>   assume for now it will be fixed one way or another before Eq becomes
>   a single method class.

I'm a bit lost.  If there's no performance benefit then what is the
benefit?  Your original email alluded to

> it’s awkward to explain “this mechanism is useful if you can have an
> optimized implementation, but, eh, here it isn’t really possible”.

Is that really the whole motivation?  It's awkward?  If so then
breaking every library maintainer who has ever added an explicit
definition of (/=) seems like far too high a price to pay.  Haskell
library maintainers are already crying out about the burden of simply
keeping up with breaking changes (I see it a lot on Twitter).  The
amount of churn here for little benefit seems overwhelming.

Tom

From hecate at glitchbra.in  Mon Oct 25 11:21:45 2021
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Mon, 25 Oct 2021 13:21:45 +0200
Subject: Proposal: Make Eq type class single method
In-Reply-To: <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
Message-ID: <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>

Hi Joachim,

Thank you for this summary of your findings.

In echo with Tom Ellis' response, I too find the added benefits a tad 
too slim when compared to the changes that will have to be undertaken by 
package authors who have (/=) defined in their instances.
Let's focus on tackling problems that have plagued us for way too long 
instead! :)

Cheers,
Hécate

Le 25/10/2021 à 11:04, Joachim Breitner a écrit :
> Hi,
>
> current status of this train of thought:
>
> * Most people here were sympathetic about the removal of (/=) from Eq.
>
> * It would break a bit of code, but with an easy and backward-
>    compatible fix.
>
> * The GHC implementation is straight forward:
>    https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6793
>
> * There is _no_ measurable performance benefit in real-world-code.
>    A few of GHC’s perf regression tests benefit slightly:
>
>      T12234(optasm) ghc/alloc    57633544.0    55409592.0  -3.9% GOOD
>      T18304(normal) ghc/alloc    87566616.0    83503296.0  -4.6% GOOD
>        T783(normal) ghc/alloc   389240752.0   377482584.0  -3.0% GOOD
>       T1969(normal) ghc/max    19869024.0    19071720.0  -4.0%
>      T11545(normal) ghc/max    35580832.0    33828936.0  -4.9%
>
> * There is a problem with rules matching on class ops of single method
>    classes: https://gitlab.haskell.org/ghc/ghc/-/issues/20535
>    I consider this a GHC bug that needs to be fixed anyways, so let’s
>    assume for now it will be fixed one way or another before Eq becomes
>    a single method class.
>
> With this, I’d like to formally bring this change before the CLC, and
> ask for its support for (or explicit rejection of) this change.
>
> Cheers,
> Joachim
>    
>
-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD


From mail at joachim-breitner.de  Mon Oct 25 13:22:07 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 25 Oct 2021 15:22:07 +0200
Subject: Proposal: Make Eq type class single method
In-Reply-To: <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
Message-ID: <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>

Hi,

ah, yes, let me summarize my main motivation (perf benefits were just a
side-benefit I was hoping for):

You can’t implement (/=) faster than (==) (up to, in the worst case,
the cost of a single `not`, which often gets optimized away anyways). 

As such, having (/=) in Eq was a (small) mistake back then, and it’s
worth fixing.

There is one time cost of asking developers to _remove_ code. But code
that was probably not worth writing in the first place! And I don’t
blame them, the Eq class _invites_ writing that code.

Then the benefits are twofold:
 
 * No more awkwards explanations about silly things in the likely first
   type class that developers care about.

 * Less code to read, maintain, compile in all the libraries that _do_
   define (/=) right now.

 * Devs who instantiate Eq in the future will not be tricked into 
   wondering if they need to implement (/=) and why.

So even if “helps teaching beginners” doesn’t beat “having to bug
maintainers”, then maybe the second point (“saving all develpers time
and effort in the future”) does?

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From ollie at ocharles.org.uk  Mon Oct 25 13:27:54 2021
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Mon, 25 Oct 2021 14:27:54 +0100
Subject: Proposal: Make Eq type class single method
In-Reply-To: <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
Message-ID: <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>

I'd like to also add that there is another benefit - correctness.

 * Eq is easier to get right/harder to get wrong. Currently if you hand roll Eq, you could potentially implement both == and /=, but get one or the other wrong. With only == as a method, as long as you get that right, you are guaranteed that /= is also right.

On Mon, 25 Oct 2021, at 2:22 PM, Joachim Breitner wrote:
> Hi,
> 
> ah, yes, let me summarize my main motivation (perf benefits were just a
> side-benefit I was hoping for):
> 
> You can’t implement (/=) faster than (==) (up to, in the worst case,
> the cost of a single `not`, which often gets optimized away anyways). 
> 
> As such, having (/=) in Eq was a (small) mistake back then, and it’s
> worth fixing.
> 
> There is one time cost of asking developers to _remove_ code. But code
> that was probably not worth writing in the first place! And I don’t
> blame them, the Eq class _invites_ writing that code.
> 
> Then the benefits are twofold:
>  
> * No more awkwards explanations about silly things in the likely first
>    type class that developers care about.
> 
> * Less code to read, maintain, compile in all the libraries that _do_
>    define (/=) right now.
> 
> * Devs who instantiate Eq in the future will not be tricked into 
>    wondering if they need to implement (/=) and why.
> 
> So even if “helps teaching beginners” doesn’t beat “having to bug
> maintainers”, then maybe the second point (“saving all develpers time
> and effort in the future”) does?
> 
> Cheers,
> Joachim
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> 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/20211025/4087bd48/attachment.html>

From carter.schonwald at gmail.com  Mon Oct 25 14:10:37 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 25 Oct 2021 10:10:37 -0400
Subject: Proposal: Make Eq type class single method
In-Reply-To: <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
Message-ID: <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>

i agree with Tom and Hecate,
more strongly:
https://github.com/ghc/ghc/blob/98aa29d3fe447cce3407e6864b015892244bb475/libraries/ghc-prim/GHC/Classes.hs#L142-L150

the current definition DOES NOT require defining both.

as it currently stands, you only need to define one of '==' *XOR*  '/='

this actually suggests an interesting and DIFFERENT ecosystem improvement,
(ignoring IEEE non-signalling NANs),
namely we add support for XOR to minimal pragma syntax and issue a warning

perhaps something like adding *(XOR "reason String" clauseExpr1
clauseexpr2)* ?

in which case for the Eq  the example useage would be something like

{-# MINIMAL ((== ) || (/=))  & (XOR "it is seldom correct to define both ==
and /= explicitly, please be careful!" (==) (/=)) #-}

this also seems like a "newish contributor" ish friendly improvement in our
minimal pragma facilities that could be useful for other examples?

On Mon, Oct 25, 2021 at 9:29 AM Oliver Charles <ollie at ocharles.org.uk>
wrote:

> I'd like to also add that there is another benefit - correctness.
>
>
>    - Eq is easier to get right/harder to get wrong. Currently if you hand
>    roll Eq, you could potentially implement both == and /=, but get one or the
>    other wrong. With only == as a method, as long as you get that right, you
>    are guaranteed that /= is also right.
>
>
> On Mon, 25 Oct 2021, at 2:22 PM, Joachim Breitner wrote:
>
> Hi,
>
> ah, yes, let me summarize my main motivation (perf benefits were just a
> side-benefit I was hoping for):
>
> You can’t implement (/=) faster than (==) (up to, in the worst case,
> the cost of a single `not`, which often gets optimized away anyways).
>
> As such, having (/=) in Eq was a (small) mistake back then, and it’s
> worth fixing.
>
> There is one time cost of asking developers to _remove_ code. But code
> that was probably not worth writing in the first place! And I don’t
> blame them, the Eq class _invites_ writing that code.
>
> Then the benefits are twofold:
>
> * No more awkwards explanations about silly things in the likely first
>    type class that developers care about.
>
> * Less code to read, maintain, compile in all the libraries that _do_
>    define (/=) right now.
>
> * Devs who instantiate Eq in the future will not be tricked into
>    wondering if they need to implement (/=) and why.
>
> So even if “helps teaching beginners” doesn’t beat “having to bug
> maintainers”, then maybe the second point (“saving all develpers time
> and effort in the future”) does?
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> 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/20211025/0b42dd5a/attachment.html>

From dhelta.diaz at gmail.com  Mon Oct 25 15:04:33 2021
From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=)
Date: Mon, 25 Oct 2021 17:04:33 +0200
Subject: Proposal: Make Eq type class single method
In-Reply-To: <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
 <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
Message-ID: <CAJFXAQgtP3H8iSAijzTggU8BRNSSmFh21AxbdkuiWoMHx0jXUQ@mail.gmail.com>

Something I like about the current definition of Eq is that I can choose
which method to implement. If (/=) is more convenient, I implement that one
and leave the other as default, and viceversa.

Am Mo., 25. Okt. 2021 um 16:11 Uhr schrieb Carter Schonwald <
carter.schonwald at gmail.com>:

> i agree with Tom and Hecate,
> more strongly:
> https://github.com/ghc/ghc/blob/98aa29d3fe447cce3407e6864b015892244bb475/libraries/ghc-prim/GHC/Classes.hs#L142-L150
>
> the current definition DOES NOT require defining both.
>
> as it currently stands, you only need to define one of '==' *XOR*  '/='
>
> this actually suggests an interesting and DIFFERENT ecosystem improvement,
> (ignoring IEEE non-signalling NANs),
> namely we add support for XOR to minimal pragma syntax and issue a warning
>
> perhaps something like adding *(XOR "reason String" clauseExpr1
> clauseexpr2)* ?
>
> in which case for the Eq  the example useage would be something like
>
> {-# MINIMAL ((== ) || (/=))  & (XOR "it is seldom correct to define both
> == and /= explicitly, please be careful!" (==) (/=)) #-}
>
> this also seems like a "newish contributor" ish friendly improvement in
> our minimal pragma facilities that could be useful for other examples?
>
> On Mon, Oct 25, 2021 at 9:29 AM Oliver Charles <ollie at ocharles.org.uk>
> wrote:
>
>> I'd like to also add that there is another benefit - correctness.
>>
>>
>>    - Eq is easier to get right/harder to get wrong. Currently if you
>>    hand roll Eq, you could potentially implement both == and /=, but get one
>>    or the other wrong. With only == as a method, as long as you get that
>>    right, you are guaranteed that /= is also right.
>>
>>
>> On Mon, 25 Oct 2021, at 2:22 PM, Joachim Breitner wrote:
>>
>> Hi,
>>
>> ah, yes, let me summarize my main motivation (perf benefits were just a
>> side-benefit I was hoping for):
>>
>> You can’t implement (/=) faster than (==) (up to, in the worst case,
>> the cost of a single `not`, which often gets optimized away anyways).
>>
>> As such, having (/=) in Eq was a (small) mistake back then, and it’s
>> worth fixing.
>>
>> There is one time cost of asking developers to _remove_ code. But code
>> that was probably not worth writing in the first place! And I don’t
>> blame them, the Eq class _invites_ writing that code.
>>
>> Then the benefits are twofold:
>>
>> * No more awkwards explanations about silly things in the likely first
>>    type class that developers care about.
>>
>> * Less code to read, maintain, compile in all the libraries that _do_
>>    define (/=) right now.
>>
>> * Devs who instantiate Eq in the future will not be tricked into
>>    wondering if they need to implement (/=) and why.
>>
>> So even if “helps teaching beginners” doesn’t beat “having to bug
>> maintainers”, then maybe the second point (“saving all develpers time
>> and effort in the future”) does?
>>
>> Cheers,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> 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/20211025/92ed5490/attachment.html>

From hecate at glitchbra.in  Mon Oct 25 16:06:46 2021
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Mon, 25 Oct 2021 18:06:46 +0200
Subject: Proposal: Make Eq type class single method
In-Reply-To: <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
Message-ID: <28322cce-c533-e91c-e53b-b40aa71186ef@glitchbra.in>

Hi Joachim :)

I will have to express a friendly but firm disagreement on the argument of a
"one time cost".
You will also have to open PRs for every library, change pedagogical 
material,
broadcast those changes to developers, and provide scripts for code-modding
tools in order to automate this on proprietary codebases.

Side-proposal

If you really want to break a bunch of things and fix mistake of the past,
I would suggest to really go for the throat and have PartialEq, 
PartialOrd, Eq, and Ord

We could finally get rid of the Eq instance for the various IEEE types 
like Double, and promote
property testing to the wider public to verify that the laws are indeed 
respected by the implementations.


module NewClasses where

import Prelude hiding (Eq(..), Ord(..))

-- | Equality comparisons which are partial equivalence relations.
class PartialEq a where
   (==) :: a -> a -> Bool

-- | Equality comparisons which are equivalence relations.
-- It is laws-only and manual implementations would be
-- verified through property testing.
class PartialEq a => Eq a

-- | Partial order
class PartialEq a => PartialOrd a where
   compare' :: a -> a -> Maybe Ordering
   (<) :: a -> a -> Bool
   (<=) :: a -> a -> Bool
   (>) :: a -> a -> Bool
   (>=) :: a -> a -> Bool

-- | Total order
class (PartialOrd a, Eq a) => Ord a where
   compare :: a -> a -> Ordering
   max :: a -> a -> a
   min :: a -> a -> a


Cheers,
Hécate

Le 25/10/2021 à 15:22, Joachim Breitner a écrit :
> Hi,
>
> ah, yes, let me summarize my main motivation (perf benefits were just a
> side-benefit I was hoping for):
>
> You can’t implement (/=) faster than (==) (up to, in the worst case,
> the cost of a single `not`, which often gets optimized away anyways).
>
> As such, having (/=) in Eq was a (small) mistake back then, and it’s
> worth fixing.
>
> There is one time cost of asking developers to _remove_ code. But code
> that was probably not worth writing in the first place! And I don’t
> blame them, the Eq class _invites_ writing that code.
>
> Then the benefits are twofold:
>   
>   * No more awkwards explanations about silly things in the likely first
>     type class that developers care about.
>
>   * Less code to read, maintain, compile in all the libraries that _do_
>     define (/=) right now.
>
>   * Devs who instantiate Eq in the future will not be tricked into
>     wondering if they need to implement (/=) and why.
>
> So even if “helps teaching beginners” doesn’t beat “having to bug
> maintainers”, then maybe the second point (“saving all develpers time
> and effort in the future”) does?
>
> Cheers,
> Joachim

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD


From ryan at trinkle.org  Mon Oct 25 17:05:59 2021
From: ryan at trinkle.org (Ryan Trinkle)
Date: Mon, 25 Oct 2021 17:05:59 +0000
Subject: Proposal: Make Eq type class single method
In-Reply-To: <28322cce-c533-e91c-e53b-b40aa71186ef@glitchbra.in>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <28322cce-c533-e91c-e53b-b40aa71186ef@glitchbra.in>
Message-ID: <7D6D4326-4D9E-4F9B-B7BB-D12592B4238D@trinkle.org>

Is there a language feature that could be built that would reduce the cost of inter-package refactors like this in the future?

On October 25, 2021 4:06:46 PM UTC, "Hécate" <hecate at glitchbra.in> wrote:
>Hi Joachim :)
>
>I will have to express a friendly but firm disagreement on the argument of a
>"one time cost".
>You will also have to open PRs for every library, change pedagogical 
>material,
>broadcast those changes to developers, and provide scripts for code-modding
>tools in order to automate this on proprietary codebases.
>
>Side-proposal
>
>If you really want to break a bunch of things and fix mistake of the past,
>I would suggest to really go for the throat and have PartialEq, 
>PartialOrd, Eq, and Ord
>
>We could finally get rid of the Eq instance for the various IEEE types 
>like Double, and promote
>property testing to the wider public to verify that the laws are indeed 
>respected by the implementations.
>
>
>module NewClasses where
>
>import Prelude hiding (Eq(..), Ord(..))
>
>-- | Equality comparisons which are partial equivalence relations.
>class PartialEq a where
>   (==) :: a -> a -> Bool
>
>-- | Equality comparisons which are equivalence relations.
>-- It is laws-only and manual implementations would be
>-- verified through property testing.
>class PartialEq a => Eq a
>
>-- | Partial order
>class PartialEq a => PartialOrd a where
>   compare' :: a -> a -> Maybe Ordering
>   (<) :: a -> a -> Bool
>   (<=) :: a -> a -> Bool
>   (>) :: a -> a -> Bool
>   (>=) :: a -> a -> Bool
>
>-- | Total order
>class (PartialOrd a, Eq a) => Ord a where
>   compare :: a -> a -> Ordering
>   max :: a -> a -> a
>   min :: a -> a -> a
>
>
>Cheers,
>Hécate
>
>Le 25/10/2021 à 15:22, Joachim Breitner a écrit :
>> Hi,
>>
>> ah, yes, let me summarize my main motivation (perf benefits were just a
>> side-benefit I was hoping for):
>>
>> You can’t implement (/=) faster than (==) (up to, in the worst case,
>> the cost of a single `not`, which often gets optimized away anyways).
>>
>> As such, having (/=) in Eq was a (small) mistake back then, and it’s
>> worth fixing.
>>
>> There is one time cost of asking developers to _remove_ code. But code
>> that was probably not worth writing in the first place! And I don’t
>> blame them, the Eq class _invites_ writing that code.
>>
>> Then the benefits are twofold:
>>   
>>   * No more awkwards explanations about silly things in the likely first
>>     type class that developers care about.
>>
>>   * Less code to read, maintain, compile in all the libraries that _do_
>>     define (/=) right now.
>>
>>   * Devs who instantiate Eq in the future will not be tricked into
>>     wondering if they need to implement (/=) and why.
>>
>> So even if “helps teaching beginners” doesn’t beat “having to bug
>> maintainers”, then maybe the second point (“saving all develpers time
>> and effort in the future”) does?
>>
>> Cheers,
>> Joachim
>
>-- 
>Hécate ✨
>🐦: @TechnoEmpress
>IRC: Hecate
>WWW: https://glitchbra.in
>RUN: BSD
>
>_______________________________________________
>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/20211025/0471cfa7/attachment.html>

From hecate at glitchbra.in  Mon Oct 25 20:50:04 2021
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Mon, 25 Oct 2021 22:50:04 +0200
Subject: Proposal: Make Eq type class single method
In-Reply-To: <7D6D4326-4D9E-4F9B-B7BB-D12592B4238D@trinkle.org>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <28322cce-c533-e91c-e53b-b40aa71186ef@glitchbra.in>
 <7D6D4326-4D9E-4F9B-B7BB-D12592B4238D@trinkle.org>
Message-ID: <ea79ba74-0383-d19c-0aca-c029784b3bc4@glitchbra.in>

There are the DefaultSuperclassInstances and Intrinsic Superclasses 
which aim to provide in-compiler support for such transitions:

https://gitlab.haskell.org/ghc/ghc/-/wikis/intrinsic-superclasses

But also code-modding would benefit from being used here, and maybe 
retrie (https://hackage.haskell.org/package/retrie)
would benefit from being used at scale?


Le 25/10/2021 à 19:05, Ryan Trinkle a écrit :
> Is there a language feature that could be built that would reduce the 
> cost of inter-package refactors like this in the future?
>
> On October 25, 2021 4:06:46 PM UTC, "Hécate" <hecate at glitchbra.in> wrote:
>
>     Hi Joachim :)
>
>     I will have to express a friendly but firm disagreement on the argument of a
>     "one time cost".
>     You will also have to open PRs for every library, change pedagogical
>     material,
>     broadcast those changes to developers, and provide scripts for code-modding
>     tools in order to automate this on proprietary codebases.
>
>     Side-proposal
>
>     If you really want to break a bunch of things and fix mistake of the past,
>     I would suggest to really go for the throat and have PartialEq,
>     PartialOrd, Eq, and Ord
>
>     We could finally get rid of the Eq instance for the various IEEE types
>     like Double, and promote
>     property testing to the wider public to verify that the laws are indeed
>     respected by the implementations.
>
>
>     module NewClasses where
>
>     import Prelude hiding (Eq(..), Ord(..))
>
>     -- | Equality comparisons which are partial equivalence relations.
>     class PartialEq a where
>         (==) :: a -> a -> Bool
>
>     -- | Equality comparisons which are equivalence relations.
>     -- It is laws-only and manual implementations would be
>     -- verified through property testing.
>     class PartialEq a => Eq a
>
>     -- | Partial order
>     class PartialEq a => PartialOrd a where
>         compare' :: a -> a -> Maybe Ordering
>         (<) :: a -> a -> Bool
>         (<=) :: a -> a -> Bool
>         (>) :: a -> a -> Bool
>         (>=) :: a -> a -> Bool
>
>     -- | Total order
>     class (PartialOrd a, Eq a) => Ord a where
>         compare :: a -> a -> Ordering
>         max :: a -> a -> a
>         min :: a -> a -> a
>
>
>     Cheers,
>     Hécate
>
>     Le 25/10/2021 à 15:22, Joachim Breitner a écrit :
>
>         Hi, ah, yes, let me summarize my main motivation (perf
>         benefits were just a side-benefit I was hoping for): You can’t
>         implement (/=) faster than (==) (up to, in the worst case, the
>         cost of a single `not`, which often gets optimized away
>         anyways). As such, having (/=) in Eq was a (small) mistake
>         back then, and it’s worth fixing. There is one time cost of
>         asking developers to _remove_ code. But code that was probably
>         not worth writing in the first place! And I don’t blame them,
>         the Eq class _invites_ writing that code. Then the benefits
>         are twofold: * No more awkwards explanations about silly
>         things in the likely first type class that developers care
>         about. * Less code to read, maintain, compile in all the
>         libraries that _do_ define (/=) right now. * Devs who
>         instantiate Eq in the future will not be tricked into
>         wondering if they need to implement (/=) and why. So even if
>         “helps teaching beginners” doesn’t beat “having to bug
>         maintainers”, then maybe the second point (“saving all
>         develpers time and effort in the future”) does? Cheers, Joachim 
>
>
>     -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW:
>     https://glitchbra.in RUN: BSD
>     ------------------------------------------------------------------------
>     Libraries mailing list Libraries at haskell.org
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW:https://glitchbra.in
RUN: BSD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211025/ba3dad63/attachment.html>

From lists at richarde.dev  Mon Oct 25 21:02:48 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 25 Oct 2021 21:02:48 +0000
Subject: Proposal: Make Eq type class single method
In-Reply-To: <ea79ba74-0383-d19c-0aca-c029784b3bc4@glitchbra.in>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <28322cce-c533-e91c-e53b-b40aa71186ef@glitchbra.in>
 <7D6D4326-4D9E-4F9B-B7BB-D12592B4238D@trinkle.org>
 <ea79ba74-0383-d19c-0aca-c029784b3bc4@glitchbra.in>
Message-ID: <010f017cb9434d5c-1400f594-ee8e-41c9-b1be-dc86b7ad64d3-000000@us-east-2.amazonses.com>

I will also offer my own counter-proposal to intrinsic-superclasses, at https://gitlab.haskell.org/ghc/ghc/-/wikis/instance-templates.

These all predate our current proposals process.

I believe they were all conceived to solve the Applicative/Monad problem (for those of you who weren't around then: Applicative was not always a superclass of Monad), and I'm not sure they will work perfectly here: we might need to make a new class, say, Equality and keep the current Eq as a subclass.

Do look at the proposals, but your mileage may vary.

Richard

> On Oct 25, 2021, at 4:50 PM, Hécate <hecate at glitchbra.in> wrote:
> 
> There are the DefaultSuperclassInstances and Intrinsic Superclasses which aim to provide in-compiler support for such transitions:
> 
> https://gitlab.haskell.org/ghc/ghc/-/wikis/intrinsic-superclasses <https://gitlab.haskell.org/ghc/ghc/-/wikis/intrinsic-superclasses>
> 
> But also code-modding would benefit from being used here, and maybe retrie (https://hackage.haskell.org/package/retrie <https://hackage.haskell.org/package/retrie>) 
> would benefit from being used at scale?
> 
> 
> 
> Le 25/10/2021 à 19:05, Ryan Trinkle a écrit :
>> Is there a language feature that could be built that would reduce the cost of inter-package refactors like this in the future?
>> 
>> On October 25, 2021 4:06:46 PM UTC, "Hécate" <hecate at glitchbra.in> <mailto:hecate at glitchbra.in> wrote:
>> Hi Joachim :)
>> 
>> I will have to express a friendly but firm disagreement on the argument of a
>> "one time cost".
>> You will also have to open PRs for every library, change pedagogical 
>> material,
>> broadcast those changes to developers, and provide scripts for code-modding
>> tools in order to automate this on proprietary codebases.
>> 
>> Side-proposal
>> 
>> If you really want to break a bunch of things and fix mistake of the past,
>> I would suggest to really go for the throat and have PartialEq, 
>> PartialOrd, Eq, and Ord
>> 
>> We could finally get rid of the Eq instance for the various IEEE types 
>> like Double, and promote
>> property testing to the wider public to verify that the laws are indeed 
>> respected by the implementations.
>> 
>> 
>> module NewClasses where
>> 
>> import Prelude hiding (Eq(..), Ord(..))
>> 
>> -- | Equality comparisons which are partial equivalence relations.
>> class PartialEq a where
>>    (==) :: a -> a -> Bool
>> 
>> -- | Equality comparisons which are equivalence relations.
>> -- It is laws-only and manual implementations would be
>> -- verified through property testing.
>> class PartialEq a => Eq a
>> 
>> -- | Partial order
>> class PartialEq a => PartialOrd a where
>>    compare' :: a -> a -> Maybe Ordering
>>    (<) :: a -> a -> Bool
>>    (<=) :: a -> a -> Bool
>>    (>) :: a -> a -> Bool
>>    (>=) :: a -> a -> Bool
>> 
>> -- | Total order
>> class (PartialOrd a, Eq a) => Ord a where
>>    compare :: a -> a -> Ordering
>>    max :: a -> a -> a
>>    min :: a -> a -> a
>> 
>> 
>> Cheers,
>> Hécate
>> 
>> Le 25/10/2021 à 15:22, Joachim Breitner a écrit :
>> Hi,
>> 
>> ah, yes, let me summarize my main motivation (perf benefits were just a
>> side-benefit I was hoping for):
>> 
>> You can’t implement (/=) faster than (==) (up to, in the worst case,
>> the cost of a single `not`, which often gets optimized away anyways).
>> 
>> As such, having (/=) in Eq was a (small) mistake back then, and it’s
>> worth fixing.
>> 
>> There is one time cost of asking developers to _remove_ code. But code
>> that was probably not worth writing in the first place! And I don’t
>> blame them, the Eq class _invites_ writing that code.
>> 
>> Then the benefits are twofold:
>>   
>>   * No more awkwards explanations about silly things in the likely first
>>     type class that developers care about.
>> 
>>   * Less code to read, maintain, compile in all the libraries that _do_
>>     define (/=) right now.
>> 
>>   * Devs who instantiate Eq in the future will not be tricked into
>>     wondering if they need to implement (/=) and why.
>> 
>> So even if “helps teaching beginners” doesn’t beat “having to bug
>> maintainers”, then maybe the second point (“saving all develpers time
>> and effort in the future”) does?
>> 
>> Cheers,
>> Joachim
>> 
>> -- 
>> Hécate ✨
>> 🐦: @TechnoEmpress
>> IRC: Hecate
>> WWW: https://glitchbra.in <https://glitchbra.in/>
>> RUN: BSD
>> 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>
> -- 
> Hécate ✨
> 🐦: @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in <https://glitchbra.in/>
> RUN: BSD
> _______________________________________________
> 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/20211025/f4c774eb/attachment.html>

From hecate at glitchbra.in  Tue Oct 26 12:22:41 2021
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Tue, 26 Oct 2021 14:22:41 +0200
Subject: Proposal: Make Eq type class single method
In-Reply-To: <010f017cb9434d5c-1400f594-ee8e-41c9-b1be-dc86b7ad64d3-000000@us-east-2.amazonses.com>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <28322cce-c533-e91c-e53b-b40aa71186ef@glitchbra.in>
 <7D6D4326-4D9E-4F9B-B7BB-D12592B4238D@trinkle.org>
 <ea79ba74-0383-d19c-0aca-c029784b3bc4@glitchbra.in>
 <010f017cb9434d5c-1400f594-ee8e-41c9-b1be-dc86b7ad64d3-000000@us-east-2.amazonses.com>
Message-ID: <434f85b3-12ae-bca9-3ad7-449f4c051f13@glitchbra.in>

Thanks a lot Richard!

Le 25/10/2021 à 23:02, Richard Eisenberg a écrit :
> I will also offer my own counter-proposal to intrinsic-superclasses, 
> at https://gitlab.haskell.org/ghc/ghc/-/wikis/instance-templates.
>
> These all predate our current proposals process.
>
> I believe they were all conceived to solve the Applicative/Monad 
> problem (for those of you who weren't around then: Applicative was not 
> always a superclass of Monad), and I'm not sure they will work 
> perfectly here: we might need to make a new class, say, Equality and 
> keep the current Eq as a subclass.
>
> Do look at the proposals, but your mileage may vary.
>
> Richard
>
>> On Oct 25, 2021, at 4:50 PM, Hécate <hecate at glitchbra.in> wrote:
>>
>> There are the DefaultSuperclassInstances and Intrinsic Superclasses 
>> which aim to provide in-compiler support for such transitions:
>>
>> https://gitlab.haskell.org/ghc/ghc/-/wikis/intrinsic-superclasses
>>
>> But also code-modding would benefit from being used here, and maybe 
>> retrie (https://hackage.haskell.org/package/retrie)
>> would benefit from being used at scale?
>>
>>
>> Le 25/10/2021 à 19:05, Ryan Trinkle a écrit :
>>> Is there a language feature that could be built that would reduce 
>>> the cost of inter-package refactors like this in the future?
>>>
>>> On October 25, 2021 4:06:46 PM UTC, "Hécate" <hecate at glitchbra.in> 
>>> wrote:
>>>
>>>     Hi Joachim :)
>>>
>>>     I will have to express a friendly but firm disagreement on the argument of a
>>>     "one time cost".
>>>     You will also have to open PRs for every library, change pedagogical
>>>     material,
>>>     broadcast those changes to developers, and provide scripts for code-modding
>>>     tools in order to automate this on proprietary codebases.
>>>
>>>     Side-proposal
>>>
>>>     If you really want to break a bunch of things and fix mistake of the past,
>>>     I would suggest to really go for the throat and have PartialEq,
>>>     PartialOrd, Eq, and Ord
>>>
>>>     We could finally get rid of the Eq instance for the various IEEE types
>>>     like Double, and promote
>>>     property testing to the wider public to verify that the laws are indeed
>>>     respected by the implementations.
>>>
>>>
>>>     module NewClasses where
>>>
>>>     import Prelude hiding (Eq(..), Ord(..))
>>>
>>>     -- | Equality comparisons which are partial equivalence relations.
>>>     class PartialEq a where
>>>         (==) :: a -> a -> Bool
>>>
>>>     -- | Equality comparisons which are equivalence relations.
>>>     -- It is laws-only and manual implementations would be
>>>     -- verified through property testing.
>>>     class PartialEq a => Eq a
>>>
>>>     -- | Partial order
>>>     class PartialEq a => PartialOrd a where
>>>         compare' :: a -> a -> Maybe Ordering
>>>         (<) :: a -> a -> Bool
>>>         (<=) :: a -> a -> Bool
>>>         (>) :: a -> a -> Bool
>>>         (>=) :: a -> a -> Bool
>>>
>>>     -- | Total order
>>>     class (PartialOrd a, Eq a) => Ord a where
>>>         compare :: a -> a -> Ordering
>>>         max :: a -> a -> a
>>>         min :: a -> a -> a
>>>
>>>
>>>     Cheers,
>>>     Hécate
>>>
>>>     Le 25/10/2021 à 15:22, Joachim Breitner a écrit :
>>>
>>>         Hi, ah, yes, let me summarize my main motivation (perf
>>>         benefits were just a side-benefit I was hoping for): You
>>>         can’t implement (/=) faster than (==) (up to, in the worst
>>>         case, the cost of a single `not`, which often gets optimized
>>>         away anyways). As such, having (/=) in Eq was a (small)
>>>         mistake back then, and it’s worth fixing. There is one time
>>>         cost of asking developers to _remove_ code. But code that
>>>         was probably not worth writing in the first place! And I
>>>         don’t blame them, the Eq class _invites_ writing that code.
>>>         Then the benefits are twofold: * No more awkwards
>>>         explanations about silly things in the likely first type
>>>         class that developers care about. * Less code to read,
>>>         maintain, compile in all the libraries that _do_ define (/=)
>>>         right now. * Devs who instantiate Eq in the future will not
>>>         be tricked into wondering if they need to implement (/=) and
>>>         why. So even if “helps teaching beginners” doesn’t beat
>>>         “having to bug maintainers”, then maybe the second point
>>>         (“saving all develpers time and effort in the future”) does?
>>>         Cheers, Joachim 
>>>
>>>
>>>     -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW:
>>>     https://glitchbra.in RUN: BSD
>>>     ------------------------------------------------------------------------
>>>     Libraries mailing list Libraries at haskell.org
>>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> -- 
>> Hécate ✨
>> 🐦: @TechnoEmpress
>> IRC: Hecate
>> WWW:https://glitchbra.in
>> RUN: BSD
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW:https://glitchbra.in
RUN: BSD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211026/aed2354b/attachment.html>

From mail at joachim-breitner.de  Wed Oct 27 09:26:41 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 27 Oct 2021 11:26:41 +0200
Subject: Proposal: Make Eq type class single method
In-Reply-To: <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
Message-ID: <db35d8e203ed00863d4a70e306406e101e74771d.camel@joachim-breitner.de>

Hi,

Am Montag, dem 25.10.2021 um 11:04 +0200 schrieb Joachim Breitner:
> With this, I’d like to formally bring this change before the CLC, and
> ask for its support for (or explicit rejection of) this change.

as suggested by a CLC member, I moved this proposal to
https://github.com/haskell/core-libraries-committee/issues/3

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From lemming at henning-thielemann.de  Wed Oct 27 10:38:47 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 27 Oct 2021 12:38:47 +0200 (CEST)
Subject: MINIMAL XOR (Was: Proposal: Make Eq type class single method)
In-Reply-To: <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
 <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
Message-ID: <35e5afc4-46fb-aa2-efc7-66b78b4cc0d4@henning-thielemann.de>


On Mon, 25 Oct 2021, Carter Schonwald wrote:

> i agree with Tom and Hecate,more strongly: 
>  https://github.com/ghc/ghc/blob/98aa29d3fe447cce3407e6864b015892244bb475/libraries/ghc-prim/GHC/Classes.hs#L142-L150 
> the current definition DOES NOT require defining both. 
> 
> as it currently stands, you only need to define one of '==' XOR  '/='
> 
> this actually suggests an interesting and DIFFERENT ecosystem improvement, (ignoring IEEE non-signalling NANs),
> namely we add support for XOR to minimal pragma syntax and issue a warning 
> 
> perhaps something like adding (XOR "reason String" clauseExpr1 clauseexpr2) ?

The problem of implementing two methods in a contradictory way arises for 
any OR in MINIMAL pragma, right?

From carter.schonwald at gmail.com  Wed Oct 27 15:14:45 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 27 Oct 2021 11:14:45 -0400
Subject: MINIMAL XOR (Was: Proposal: Make Eq type class single method)
In-Reply-To: <35e5afc4-46fb-aa2-efc7-66b78b4cc0d4@henning-thielemann.de>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
 <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
 <35e5afc4-46fb-aa2-efc7-66b78b4cc0d4@henning-thielemann.de>
Message-ID: <CAHYVw0yA9CYs_CLd1Xu4rO8mZZ5NYHjxnLa7etPSqqEFZaHNGA@mail.gmail.com>

not necessarily ... there could be  contradictory sets of methods! :)

like the minimal sets for Field type class,  the xor would be for defining
'/' in terms of reciprocal and times or vice versa (/ vs recip) and
likewise (negate vs minus) etc etc

On Wed, Oct 27, 2021 at 6:38 AM Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Mon, 25 Oct 2021, Carter Schonwald wrote:
>
> > i agree with Tom and Hecate,more strongly:
> >
> https://github.com/ghc/ghc/blob/98aa29d3fe447cce3407e6864b015892244bb475/libraries/ghc-prim/GHC/Classes.hs#L142-L150
>
> > the current definition DOES NOT require defining both.
> >
> > as it currently stands, you only need to define one of '==' XOR  '/='
> >
> > this actually suggests an interesting and DIFFERENT
> ecosystem improvement, (ignoring IEEE non-signalling NANs),
> > namely we add support for XOR to minimal pragma syntax and issue a
> warning
> >
> > perhaps something like adding (XOR "reason String" clauseExpr1
> clauseexpr2) ?
>
> The problem of implementing two methods in a contradictory way arises for
> any OR in MINIMAL pragma, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211027/e8ecdfe3/attachment.html>

From david.feuer at gmail.com  Wed Oct 27 15:19:45 2021
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 27 Oct 2021 11:19:45 -0400
Subject: MINIMAL XOR (Was: Proposal: Make Eq type class single method)
In-Reply-To: <CAHYVw0yA9CYs_CLd1Xu4rO8mZZ5NYHjxnLa7etPSqqEFZaHNGA@mail.gmail.com>
References: <ef01d21713da616eca1d303931cf9d25366cf303.camel@joachim-breitner.de>
 <YXAydaosAuHWmVAS@straasha.imrryr.org>
 <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
 <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
 <35e5afc4-46fb-aa2-efc7-66b78b4cc0d4@henning-thielemann.de>
 <CAHYVw0yA9CYs_CLd1Xu4rO8mZZ5NYHjxnLa7etPSqqEFZaHNGA@mail.gmail.com>
Message-ID: <CAMgWh9sS_U80JTWRCiVhdGd6aOGf5ph0FDK0ts2AAprnPTosbw@mail.gmail.com>

I think the only time they're not potentially contradictory is when you're
dealing with singletons, and that's a pretty special case.

On Wed, Oct 27, 2021, 11:15 AM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> not necessarily ... there could be  contradictory sets of methods! :)
>
> like the minimal sets for Field type class,  the xor would be for defining
> '/' in terms of reciprocal and times or vice versa (/ vs recip) and
> likewise (negate vs minus) etc etc
>
> On Wed, Oct 27, 2021 at 6:38 AM Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>
>>
>> On Mon, 25 Oct 2021, Carter Schonwald wrote:
>>
>> > i agree with Tom and Hecate,more strongly:
>> >
>> https://github.com/ghc/ghc/blob/98aa29d3fe447cce3407e6864b015892244bb475/libraries/ghc-prim/GHC/Classes.hs#L142-L150
>>
>> > the current definition DOES NOT require defining both.
>> >
>> > as it currently stands, you only need to define one of '==' XOR  '/='
>> >
>> > this actually suggests an interesting and DIFFERENT
>> ecosystem improvement, (ignoring IEEE non-signalling NANs),
>> > namely we add support for XOR to minimal pragma syntax and issue a
>> warning
>> >
>> > perhaps something like adding (XOR "reason String" clauseExpr1
>> clauseexpr2) ?
>>
>> The problem of implementing two methods in a contradictory way arises for
>> any OR in MINIMAL pragma, 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/20211027/9f7f29e2/attachment.html>

From ietf-dane at dukhovni.org  Wed Oct 27 15:32:40 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Wed, 27 Oct 2021 11:32:40 -0400
Subject: MINIMAL XOR (Was: Proposal: Make Eq type class single method)
In-Reply-To: <CAHYVw0yA9CYs_CLd1Xu4rO8mZZ5NYHjxnLa7etPSqqEFZaHNGA@mail.gmail.com>
References: <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
 <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
 <35e5afc4-46fb-aa2-efc7-66b78b4cc0d4@henning-thielemann.de>
 <CAHYVw0yA9CYs_CLd1Xu4rO8mZZ5NYHjxnLa7etPSqqEFZaHNGA@mail.gmail.com>
Message-ID: <YXlxGOv9H/crSetV@straasha.imrryr.org>

On Wed, Oct 27, 2021 at 11:14:45AM -0400, Carter Schonwald wrote:
> not necessarily ... there could be  contradictory sets of methods! :)
> 
> like the minimal sets for Field type class,  the xor would be for defining
> '/' in terms of reciprocal and times or vice versa (/ vs recip) and
> likewise (negate vs minus) etc etc

Logically redundant definitions aren't always redundant in practice if
one considers performance, floating point accuracy or even sometimes
divergence.

      For example, foldl on infinite snoc lists is not definable in
      terms of foldr which diverges, though admittedly I rather think
      that infinite snoc lists violate all reasonable expectations of
      a Foldable instance.

So in many cases redundancy warnings would not be viable.  The Eq
situation is likely more the exception that the rule.

The SQL NULL instances that are False for both "==" and "/=" look
like they could be a mistake to me, but presumably they work out
OK in practice, and I would expect that e.g. the relevant `Ord`
instances do return `EQ` for `compare Null Null`...  Less clear
is whether the non-lawful Eq defintion is in some predicably useful
way essential.

-- 
    Viktor.

From keith.wygant at gmail.com  Thu Oct 28 00:09:01 2021
From: keith.wygant at gmail.com (Keith)
Date: Thu, 28 Oct 2021 00:09:01 +0000
Subject: MINIMAL XOR (Was: Proposal: Make Eq type class single method)
In-Reply-To: <YXlxGOv9H/crSetV@straasha.imrryr.org>
References: <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
 <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
 <35e5afc4-46fb-aa2-efc7-66b78b4cc0d4@henning-thielemann.de>
 <CAHYVw0yA9CYs_CLd1Xu4rO8mZZ5NYHjxnLa7etPSqqEFZaHNGA@mail.gmail.com>
 <YXlxGOv9H/crSetV@straasha.imrryr.org>
Message-ID: <6C17B760-EB32-4AD5-91F7-1D564ADDF50A@gmail.com>

For what it's worth, Haskell says that NaN is `GT` NaN. So maybe it would also claim than NULL is `GT` NULL.

(NaN is not `==` to NaN, and is not `<=` to NaN, so it must be GT.)
—
Sent from my phone with K-9 Mail.

On 27 October 2021 15:32:40 UTC, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>On Wed, Oct 27, 2021 at 11:14:45AM -0400, Carter Schonwald wrote:
>> not necessarily ... there could be  contradictory sets of methods! :)
>> 
>> like the minimal sets for Field type class,  the xor would be for defining
>> '/' in terms of reciprocal and times or vice versa (/ vs recip) and
>> likewise (negate vs minus) etc etc
>
>Logically redundant definitions aren't always redundant in practice if
>one considers performance, floating point accuracy or even sometimes
>divergence.
>
>      For example, foldl on infinite snoc lists is not definable in
>      terms of foldr which diverges, though admittedly I rather think
>      that infinite snoc lists violate all reasonable expectations of
>      a Foldable instance.
>
>So in many cases redundancy warnings would not be viable.  The Eq
>situation is likely more the exception that the rule.
>
>The SQL NULL instances that are False for both "==" and "/=" look
>like they could be a mistake to me, but presumably they work out
>OK in practice, and I would expect that e.g. the relevant `Ord`
>instances do return `EQ` for `compare Null Null`...  Less clear
>is whether the non-lawful Eq defintion is in some predicably useful
>way essential.
>
>-- 
>    Viktor.
>_______________________________________________
>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/20211028/874d2ec5/attachment.html>

From david.feuer at gmail.com  Thu Oct 28 00:14:11 2021
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 27 Oct 2021 20:14:11 -0400
Subject: MINIMAL XOR (Was: Proposal: Make Eq type class single method)
In-Reply-To: <6C17B760-EB32-4AD5-91F7-1D564ADDF50A@gmail.com>
References: <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
 <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
 <35e5afc4-46fb-aa2-efc7-66b78b4cc0d4@henning-thielemann.de>
 <CAHYVw0yA9CYs_CLd1Xu4rO8mZZ5NYHjxnLa7etPSqqEFZaHNGA@mail.gmail.com>
 <YXlxGOv9H/crSetV@straasha.imrryr.org>
 <6C17B760-EB32-4AD5-91F7-1D564ADDF50A@gmail.com>
Message-ID: <CAMgWh9us_5DQdbYWqeUuqtEJ9nPACTaHMeSS2euzORT3v1dLMA@mail.gmail.com>

NULL is not like NaN. It's perfectly sensible to stick `NULL` in a `Set` or
something.

On Wed, Oct 27, 2021, 8:09 PM Keith <keith.wygant at gmail.com> wrote:

> For what it's worth, Haskell says that NaN is `GT` NaN. So maybe it would
> also claim than NULL is `GT` NULL.
>
> (NaN is not `==` to NaN, and is not `<=` to NaN, so it must be GT.)
> —
> Sent from my phone with K-9 Mail.
>
>
> On 27 October 2021 15:32:40 UTC, Viktor Dukhovni <ietf-dane at dukhovni.org>
> wrote:
>>
>> On Wed, Oct 27, 2021 at 11:14:45AM -0400, Carter Schonwald wrote:
>>
>>> not necessarily ... there could be  contradictory sets of methods! :)
>>>
>>> like the minimal sets for Field type class,  the xor would be for defining
>>> '/' in terms of reciprocal and times or vice versa (/ vs recip) and
>>> likewise (negate vs minus) etc etc
>>>
>>
>> Logically redundant definitions aren't always redundant in practice if
>> one considers performance, floating point accuracy or even sometimes
>> divergence.
>>
>>       For example, foldl on infinite snoc lists is not definable in
>>       terms of foldr which diverges, though admittedly I rather think
>>       that infinite snoc lists violate all reasonable expectations of
>>       a Foldable instance.
>>
>> So in many cases redundancy warnings would not be viable.  The Eq
>> situation is likely more the exception that the rule.
>>
>> The SQL NULL instances that are False for both "==" and "/=" look
>> like they could be a mistake to me, but presumably they work out
>> OK in practice, and I would expect that e.g. the relevant `Ord`
>> instances do return `EQ` for `compare Null Null`...  Less clear
>> is whether the non-lawful Eq defintion is in some predicably useful
>> way essential.
>>
>> --
>>     Viktor.
>> ------------------------------
>> 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/20211027/6f3524ed/attachment.html>

From keith.wygant at gmail.com  Thu Oct 28 02:37:33 2021
From: keith.wygant at gmail.com (Keith)
Date: Thu, 28 Oct 2021 02:37:33 +0000
Subject: MINIMAL XOR (Was: Proposal: Make Eq type class single method)
In-Reply-To: <CAMgWh9us_5DQdbYWqeUuqtEJ9nPACTaHMeSS2euzORT3v1dLMA@mail.gmail.com>
References: <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
 <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
 <35e5afc4-46fb-aa2-efc7-66b78b4cc0d4@henning-thielemann.de>
 <CAHYVw0yA9CYs_CLd1Xu4rO8mZZ5NYHjxnLa7etPSqqEFZaHNGA@mail.gmail.com>
 <YXlxGOv9H/crSetV@straasha.imrryr.org>
 <6C17B760-EB32-4AD5-91F7-1D564ADDF50A@gmail.com>
 <CAMgWh9us_5DQdbYWqeUuqtEJ9nPACTaHMeSS2euzORT3v1dLMA@mail.gmail.com>
Message-ID: <EE946AC5-D971-4C77-85C5-6A166AA67C2F@gmail.com>

Sure, you can consider NULL to be the top or bottom of the lattice. But in practice what is the point of putting it in a `Set`?

You extract all the phone numbers from a DB and stick 'em in a `Set`, and every missing number is mapped to the single NULL in the `Set`? And now you know from the `Set` that at least one number was missing?
—
Sent from my phone with K-9 Mail.

On 28 October 2021 00:14:11 UTC, David Feuer <david.feuer at gmail.com> wrote:
>NULL is not like NaN. It's perfectly sensible to stick `NULL` in a `Set` or
>something.
>
>On Wed, Oct 27, 2021, 8:09 PM Keith <keith.wygant at gmail.com> wrote:
>
>> For what it's worth, Haskell says that NaN is `GT` NaN. So maybe it would
>> also claim than NULL is `GT` NULL.
>>
>> (NaN is not `==` to NaN, and is not `<=` to NaN, so it must be GT.)
>> —
>> Sent from my phone with K-9 Mail.
>>
>>
>> On 27 October 2021 15:32:40 UTC, Viktor Dukhovni <ietf-dane at dukhovni.org>
>> wrote:
>>>
>>> On Wed, Oct 27, 2021 at 11:14:45AM -0400, Carter Schonwald wrote:
>>>
>>>> not necessarily ... there could be  contradictory sets of methods! :)
>>>>
>>>> like the minimal sets for Field type class,  the xor would be for defining
>>>> '/' in terms of reciprocal and times or vice versa (/ vs recip) and
>>>> likewise (negate vs minus) etc etc
>>>>
>>>
>>> Logically redundant definitions aren't always redundant in practice if
>>> one considers performance, floating point accuracy or even sometimes
>>> divergence.
>>>
>>>       For example, foldl on infinite snoc lists is not definable in
>>>       terms of foldr which diverges, though admittedly I rather think
>>>       that infinite snoc lists violate all reasonable expectations of
>>>       a Foldable instance.
>>>
>>> So in many cases redundancy warnings would not be viable.  The Eq
>>> situation is likely more the exception that the rule.
>>>
>>> The SQL NULL instances that are False for both "==" and "/=" look
>>> like they could be a mistake to me, but presumably they work out
>>> OK in practice, and I would expect that e.g. the relevant `Ord`
>>> instances do return `EQ` for `compare Null Null`...  Less clear
>>> is whether the non-lawful Eq defintion is in some predicably useful
>>> way essential.
>>>
>>> --
>>>     Viktor.
>>> ------------------------------
>>> 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/20211028/5553ec5f/attachment.html>

From david.feuer at gmail.com  Thu Oct 28 05:35:17 2021
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 28 Oct 2021 01:35:17 -0400
Subject: MINIMAL XOR (Was: Proposal: Make Eq type class single method)
In-Reply-To: <EE946AC5-D971-4C77-85C5-6A166AA67C2F@gmail.com>
References: <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
 <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
 <35e5afc4-46fb-aa2-efc7-66b78b4cc0d4@henning-thielemann.de>
 <CAHYVw0yA9CYs_CLd1Xu4rO8mZZ5NYHjxnLa7etPSqqEFZaHNGA@mail.gmail.com>
 <YXlxGOv9H/crSetV@straasha.imrryr.org>
 <6C17B760-EB32-4AD5-91F7-1D564ADDF50A@gmail.com>
 <CAMgWh9us_5DQdbYWqeUuqtEJ9nPACTaHMeSS2euzORT3v1dLMA@mail.gmail.com>
 <EE946AC5-D971-4C77-85C5-6A166AA67C2F@gmail.com>
Message-ID: <CAMgWh9vvs-JPJ5Z6uzp08R2hJbyvhedDB4v-RUUFdo7Wv_hufA@mail.gmail.com>

Let me put it a different way: pretty much *any* function polymorphic
over Ord types will have strange, difficult to predict behavior when
given NaN. This is a *bad* thing. The last thing we need is to add
more types with unlawful Ord instances. There is no *benefit* to
giving NULL (by which I assume you mean nullPtr?) special treatment in
this regard.

On Wed, Oct 27, 2021 at 10:38 PM Keith <keith.wygant at gmail.com> wrote:
>
> Sure, you can consider NULL to be the top or bottom of the lattice. But in practice what is the point of putting it in a `Set`?
>
> You extract all the phone numbers from a DB and stick 'em in a `Set`, and every missing number is mapped to the single NULL in the `Set`? And now you know from the `Set` that at least one number was missing?
> —
> Sent from my phone with K-9 Mail.
>
>
> On 28 October 2021 00:14:11 UTC, David Feuer <david.feuer at gmail.com> wrote:
>>
>> NULL is not like NaN. It's perfectly sensible to stick `NULL` in a `Set` or something.
>>
>> On Wed, Oct 27, 2021, 8:09 PM Keith <keith.wygant at gmail.com> wrote:
>>>
>>> For what it's worth, Haskell says that NaN is `GT` NaN. So maybe it would also claim than NULL is `GT` NULL.
>>>
>>> (NaN is not `==` to NaN, and is not `<=` to NaN, so it must be GT.)
>>> —
>>> Sent from my phone with K-9 Mail.
>>>
>>>
>>> On 27 October 2021 15:32:40 UTC, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>>>>
>>>> On Wed, Oct 27, 2021 at 11:14:45AM -0400, Carter Schonwald wrote:
>>>>>
>>>>> not necessarily ... there could be  contradictory sets of methods! :)
>>>>>
>>>>> like the minimal sets for Field type class,  the xor would be for defining
>>>>> '/' in terms of reciprocal and times or vice versa (/ vs recip) and
>>>>> likewise (negate vs minus) etc etc
>>>>
>>>>
>>>> Logically redundant definitions aren't always redundant in practice if
>>>> one considers performance, floating point accuracy or even sometimes
>>>> divergence.
>>>>
>>>>       For example, foldl on infinite snoc lists is not definable in
>>>>       terms of foldr which diverges, though admittedly I rather think
>>>>       that infinite snoc lists violate all reasonable expectations of
>>>>       a Foldable instance.
>>>>
>>>> So in many cases redundancy warnings would not be viable.  The Eq
>>>> situation is likely more the exception that the rule.
>>>>
>>>> The SQL NULL instances that are False for both "==" and "/=" look
>>>> like they could be a mistake to me, but presumably they work out
>>>> OK in practice, and I would expect that e.g. the relevant `Ord`
>>>> instances do return `EQ` for `compare Null Null`...  Less clear
>>>> is whether the non-lawful Eq defintion is in some predicably useful
>>>> way essential.
>>>>
>>>> --
>>>>     Viktor.
>>>> ________________________________
>>>> 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 keith.wygant at gmail.com  Thu Oct 28 13:23:21 2021
From: keith.wygant at gmail.com (Keith)
Date: Thu, 28 Oct 2021 13:23:21 +0000
Subject: MINIMAL XOR (Was: Proposal: Make Eq type class single method)
In-Reply-To: <CAMgWh9vvs-JPJ5Z6uzp08R2hJbyvhedDB4v-RUUFdo7Wv_hufA@mail.gmail.com>
References: <feec37e3-ec0c-ddb0-7893-f439d5dd11da@iki.fi>
 <c6d7cf629115de649be264df864568b1b5f45507.camel@joachim-breitner.de>
 <779b47d267e69808d24d1f397fc4f1d93ca6a70c.camel@joachim-breitner.de>
 <0f0460af48efe4de659ae4779fe66473a5325fb9.camel@joachim-breitner.de>
 <b3c2feab-0133-0ab5-070e-fe31351bcd83@glitchbra.in>
 <90a5b49d1d342de57a50b158622e63ebde7d9c03.camel@joachim-breitner.de>
 <0a989e78-deda-4039-8f41-bb0dac9d4386@www.fastmail.com>
 <CAHYVw0wLqJxnEWzS8+oibmPKnVZmkzu_yA0VYvY0WHsJJU5AdQ@mail.gmail.com>
 <35e5afc4-46fb-aa2-efc7-66b78b4cc0d4@henning-thielemann.de>
 <CAHYVw0yA9CYs_CLd1Xu4rO8mZZ5NYHjxnLa7etPSqqEFZaHNGA@mail.gmail.com>
 <YXlxGOv9H/crSetV@straasha.imrryr.org>
 <6C17B760-EB32-4AD5-91F7-1D564ADDF50A@gmail.com>
 <CAMgWh9us_5DQdbYWqeUuqtEJ9nPACTaHMeSS2euzORT3v1dLMA@mail.gmail.com>
 <EE946AC5-D971-4C77-85C5-6A166AA67C2F@gmail.com>
 <CAMgWh9vvs-JPJ5Z6uzp08R2hJbyvhedDB4v-RUUFdo7Wv_hufA@mail.gmail.com>
Message-ID: <25453972-91DD-4D6F-8A9A-99DFE30D9B47@gmail.com>

No, SQL NULL. An intrinsic `Nothing`.

For the most part I agree. `compare` for `Double` is should never be emulated. With luck it allows you to sort a list of `Double`s and have the NaNs randomly distributed throughout. Without luck the sort won't terminate.
—
Sent from my phone with K-9 Mail.

On 28 October 2021 05:35:17 UTC, David Feuer <david.feuer at gmail.com> wrote:
>Let me put it a different way: pretty much *any* function polymorphic
>over Ord types will have strange, difficult to predict behavior when
>given NaN. This is a *bad* thing. The last thing we need is to add
>more types with unlawful Ord instances. There is no *benefit* to
>giving NULL (by which I assume you mean nullPtr?) special treatment in
>this regard.
>
>On Wed, Oct 27, 2021 at 10:38 PM Keith <keith.wygant at gmail.com> wrote:
>>
>> Sure, you can consider NULL to be the top or bottom of the lattice. But in practice what is the point of putting it in a `Set`?
>>
>> You extract all the phone numbers from a DB and stick 'em in a `Set`, and every missing number is mapped to the single NULL in the `Set`? And now you know from the `Set` that at least one number was missing?
>> —
>> Sent from my phone with K-9 Mail.
>>
>>
>> On 28 October 2021 00:14:11 UTC, David Feuer <david.feuer at gmail.com> wrote:
>>>
>>> NULL is not like NaN. It's perfectly sensible to stick `NULL` in a `Set` or something.
>>>
>>> On Wed, Oct 27, 2021, 8:09 PM Keith <keith.wygant at gmail.com> wrote:
>>>>
>>>> For what it's worth, Haskell says that NaN is `GT` NaN. So maybe it would also claim than NULL is `GT` NULL.
>>>>
>>>> (NaN is not `==` to NaN, and is not `<=` to NaN, so it must be GT.)
>>>> —
>>>> Sent from my phone with K-9 Mail.
>>>>
>>>>
>>>> On 27 October 2021 15:32:40 UTC, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>>>>>
>>>>> On Wed, Oct 27, 2021 at 11:14:45AM -0400, Carter Schonwald wrote:
>>>>>>
>>>>>> not necessarily ... there could be  contradictory sets of methods! :)
>>>>>>
>>>>>> like the minimal sets for Field type class,  the xor would be for defining
>>>>>> '/' in terms of reciprocal and times or vice versa (/ vs recip) and
>>>>>> likewise (negate vs minus) etc etc
>>>>>
>>>>>
>>>>> Logically redundant definitions aren't always redundant in practice if
>>>>> one considers performance, floating point accuracy or even sometimes
>>>>> divergence.
>>>>>
>>>>>       For example, foldl on infinite snoc lists is not definable in
>>>>>       terms of foldr which diverges, though admittedly I rather think
>>>>>       that infinite snoc lists violate all reasonable expectations of
>>>>>       a Foldable instance.
>>>>>
>>>>> So in many cases redundancy warnings would not be viable.  The Eq
>>>>> situation is likely more the exception that the rule.
>>>>>
>>>>> The SQL NULL instances that are False for both "==" and "/=" look
>>>>> like they could be a mistake to me, but presumably they work out
>>>>> OK in practice, and I would expect that e.g. the relevant `Ord`
>>>>> instances do return `EQ` for `compare Null Null`...  Less clear
>>>>> is whether the non-lawful Eq defintion is in some predicably useful
>>>>> way essential.
>>>>>
>>>>> --
>>>>>     Viktor.
>>>>> ________________________________
>>>>> 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/20211028/bb886fc9/attachment.html>

From ietf-dane at dukhovni.org  Fri Oct 29 01:01:10 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 28 Oct 2021 21:01:10 -0400
Subject: interaction of "local" and "callCC"?
Message-ID: <YXtH1uXiYfkAdnIf@straasha.imrryr.org>

I've stumbled into a not immediately intuitive distinction when mixing
"local" and "callCC" (from the `transformers` package) with one of:

    * ReaderT e (ContT r m) a
    * ContT r (ReaderT e m) a

Specifically, this concernts the expected `Reader` environment when the
current continuation passed via callCC is invoked.

    * With ContT as the inner monad, the Reader environment of the
      current continuation is not affeced by an enclosing call to
      "local":
       
        flip runConT finalK $
        flip runReaderT env $ do
            ...
            x <- liftCallCC callCC $ \ k -> do
                local f (ask >>= k)  
                ...
            ask >>= cc x

      in this form, `k` (i.e. `\x -> ask >>= c x`) sees the original
      environment `env` from `runReaderT`, only the first `ask` call
      sees `f env` interposed by `local`. 

    * With ReaderT as the inner monad, the environment of the
      current continuation is affeced by an enclosing call to
      "liftLocal":
       
        flip runReaderT env $
        flip runConT (lift . finalK) $ do
            ...
            x <- callCC $ \ k -> do
                liftLocal ask local f (lift ask >>= k)  
                ...
            lift ask >>= cc x

      in this form, both `k` and the firt `lift ask` see the modified
      environment `f env` interposed by `liftLocal`. 

Of course in the simple example above, one could just write:

    liftLocal ask local f (lift ask) >>= k

and avoid the issue, but in more complex nesting of code, this can be
rather more difficult.

My intuition is that the behaviour when ContT is the inner monad (first
example) is closer to what one might generally hope to see.

The rationale is that a more flexible definition of `local` and
`liftLocal` might be generalised from taking `f :: env -> env` to taking
`f :: env -> newenv` for some related environment type `newenv`, and in
that case, the second example would no longer typecheck, because the
current continuation would now have to have both `env` and `newenv`
for its environment type.

It seems likely that the different behaviours are largely unavoidable,
because `liftLocal` does not know that there's a current continuation
that might need the original environment, and `callCC` does not know
that the base monad is a `ReaderT` and the current continuation needs to
see the Reader's original environment.

It seems this issue is explicitly covered in the case of StateT:

    -- | Uniform lifting of a @callCC@ operation to the new monad.
    -- This version rolls back to the original state on entering the
    -- continuation.
    liftCallCC :: CallCC m (a,s) (b,s) -> CallCC (StateT s m) a b
    liftCallCC callCC f = StateT $ \ s ->
        callCC $ \ c ->
        runStateT (f (\ a -> StateT $ \ _ -> c (a, s))) s
    {-# INLINE liftCallCC #-}

    -- | In-situ lifting of a @callCC@ operation to the new monad.
    -- This version uses the current state on entering the continuation.
    -- It does not satisfy the uniformity property (see "Control.Monad.Signatures").
    liftCallCC' :: CallCC m (a,s) (b,s) -> CallCC (StateT s m) a b
    liftCallCC' callCC f = StateT $ \ s ->
        callCC $ \ c ->
        runStateT (f (\ a -> StateT $ \ s' -> c (a, s'))) s
    {-# INLINE liftCallCC' #-}

where in the "Signatures" module we see:

    -- | Signature of the @callCC@ operation,
    -- introduced in "Control.Monad.Trans.Cont".
    -- Any lifting function @liftCallCC@ should satisfy
    --
    -- * @'lift' (f k) = f' ('lift' . k) => 'lift' (cf f) = liftCallCC cf f'@
    --
    type CallCC m a b = ((a -> m b) -> m a) -> m a

Playing with a prototype "flat" (ContT + ReaderT) monad:

    newtype RContT e r m a =
        RContT { runRContT :: (a -> e -> m r) -> e -> m r }

which directly supports both ReaderT and ContT features, I found it
natural to define a "local" that can change the environment type, and
then of course had no choice but to pass an unmodified enviroment to the
current continuation.

    local :: (e -> e')
          -> RContT e' r m a
          -> RContT e r m a
    local f m = RContT $ \k e -> runRContT m (\a _ -> k a e) (f e)

    callCC :: ((a -> RContT e' r m b)
           -> RContT e r m a)
           -> RContT e r m a
    callCC f = RContT $ \k e -> runRContT (f (\x -> RContT (\_ _ -> k x e))) k e

I don't know where it might be appropriate to document "correct" use of
callCC in transformer stacks with `ReaderT` environments.  Perhaps it
would be reasonable to document that one should generally have "ContT"
just above the base monad, and use "liftCallCC" upstairs, rather than
use "liftLocal" from ContT, unless of course one wants the current
continuation to be exposed to a modified environment in some cases.

Is there an expected "uniformity" property here that's not covered
by the "Signatures"?

-- 
    Viktor.

From andrew.lelechenko at gmail.com  Sat Oct 30 20:13:18 2021
From: andrew.lelechenko at gmail.com (Andrew Lelechenko)
Date: Sat, 30 Oct 2021 21:13:18 +0100
Subject: New CLC proposal process
Message-ID: <6690A80D-A825-4FB5-8A6A-21078B793556@gmail.com>

I'm happy to announce that Core Libraries Committee has completed post-election reboot and now has a new home at https://github.com/haskell/core-libraries-committee <https://github.com/haskell/core-libraries-committee> and a new GitHub-based process: https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md <https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md>.

From now on proposals to change base should be raised as GitHub issues instead of emails to libraries at .

Best regards,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211030/49977b53/attachment.html>

From hasufell at posteo.de  Sat Oct 30 23:08:22 2021
From: hasufell at posteo.de (Julian Ospald)
Date: Sat, 30 Oct 2021 23:08:22 +0000
Subject: New CLC proposal process
In-Reply-To: <6690A80D-A825-4FB5-8A6A-21078B793556@gmail.com>
References: <6690A80D-A825-4FB5-8A6A-21078B793556@gmail.com>
Message-ID: <7AA4202A-D081-4367-B5CC-DAA755419D86@posteo.de>

Do I understand correctly that the CLC only governs base now?

If not, where does one raise other issues that potentially affect core libraries?

On October 30, 2021 8:13:18 PM UTC, Andrew Lelechenko <andrew.lelechenko at gmail.com> wrote:
>I'm happy to announce that Core Libraries Committee has completed post-election reboot and now has a new home at https://github.com/haskell/core-libraries-committee <https://github.com/haskell/core-libraries-committee> and a new GitHub-based process: https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md <https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md>.
>
>From now on proposals to change base should be raised as GitHub issues instead of emails to libraries at .
>
>Best regards,
>Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211030/5e1623ef/attachment.html>

From andrew.lelechenko at gmail.com  Sat Oct 30 23:23:57 2021
From: andrew.lelechenko at gmail.com (Andrew Lelechenko)
Date: Sun, 31 Oct 2021 00:23:57 +0100
Subject: New CLC proposal process
In-Reply-To: <7AA4202A-D081-4367-B5CC-DAA755419D86@posteo.de>
References: <6690A80D-A825-4FB5-8A6A-21078B793556@gmail.com>
 <7AA4202A-D081-4367-B5CC-DAA755419D86@posteo.de>
Message-ID: <D3995316-7F6A-4B1C-8F22-F4C0FD698646@gmail.com>

As https://github.com/haskell/core-libraries-committee/blob/main/README.md <https://github.com/haskell/core-libraries-committee/blob/main/README.md> says, CLC owns, but does not maintain core libraries as long as they are kept in order by appointed maintainers. If you find a core library abandoned and neglected, raise an issue with CLC.

Otherwise proposals affecting core libraries should be discussed with respective maintainers first. They can seek CLC opinion on controversial changes, but are not obliged to. 

I suppose HF Tech Track could be a helpful body to ask a non-binding opinion on changes with a wider scope.

Best regards,
Andrew

> On 31 Oct 2021, at 00:08, Julian Ospald <hasufell at posteo.de> wrote:
> 
> Do I understand correctly that the CLC only governs base now?
> 
> If not, where does one raise other issues that potentially affect core libraries?
> 
> On October 30, 2021 8:13:18 PM UTC, Andrew Lelechenko <andrew.lelechenko at gmail.com> wrote:
> I'm happy to announce that Core Libraries Committee has completed post-election reboot and now has a new home at https://github.com/haskell/core-libraries-committee <https://github.com/haskell/core-libraries-committee> and a new GitHub-based process: https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md <https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md>.
> 
> From now on proposals to change base should be raised as GitHub issues instead of emails to libraries at .
> 
> Best regards,
> Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211031/1bb95d4c/attachment.html>

From hasufell at posteo.de  Sun Oct 31 09:49:13 2021
From: hasufell at posteo.de (Julian Ospald)
Date: Sun, 31 Oct 2021 09:49:13 +0000
Subject: New CLC proposal process
In-Reply-To: <D3995316-7F6A-4B1C-8F22-F4C0FD698646@gmail.com>
References: <6690A80D-A825-4FB5-8A6A-21078B793556@gmail.com>
 <7AA4202A-D081-4367-B5CC-DAA755419D86@posteo.de>
 <D3995316-7F6A-4B1C-8F22-F4C0FD698646@gmail.com>
Message-ID: <20211031094913.5oz4tczlsrh4o2h5@localhost.localdomain>

That sounds rather disappointing to me.

So what has been done to reboot the CLC is:

1. add more people and 
2. narrow the scope and offload ecosystem issues to the Haskell
   Foundation?

I've been trying to get input from the CLC for the past year on an issue
that affects potentially all of core libraries and I don't think it's feasible
to contact all of the maintainers isolated.

Does that mean CLC won't assist me in contacting core library
maintainers and moderating a discussion?


On Sun, Oct 31, 2021 at 12:23:57AM +0100, Andrew Lelechenko wrote:
> As https://github.com/haskell/core-libraries-committee/blob/main/README.md
>  says, CLC owns, but does not maintain core libraries as long as they are kept
> in order by appointed maintainers. If you find a core library abandoned and
> neglected, raise an issue with CLC.
> 
> Otherwise proposals affecting core libraries should be discussed with
> respective maintainers first. They can seek CLC opinion on controversial
> changes, but are not obliged to. 
> 
> I suppose HF Tech Track could be a helpful body to ask a non-binding opinion on
> changes with a wider scope.
> 
> Best regards,
> Andrew
> 
> 
>     On 31 Oct 2021, at 00:08, Julian Ospald <hasufell at posteo.de> wrote:
> 
>     Do I understand correctly that the CLC only governs base now?
> 
>     If not, where does one raise other issues that potentially affect core
>     libraries?
> 
>     On October 30, 2021 8:13:18 PM UTC, Andrew Lelechenko <
>     andrew.lelechenko at gmail.com> wrote:
> 
> 
>         I'm happy to announce that Core Libraries Committee has completed
>         post-election reboot and now has a new home at https://github.com/
>         haskell/core-libraries-committee and a new GitHub-based process: https:
>         //github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md.
> 
>         From now on proposals to change base should be raised as GitHub issues
>         instead of emails to libraries at .
> 
>         Best regards,
>         Andrew
> 
> 

From andrew.lelechenko at gmail.com  Sun Oct 31 12:01:55 2021
From: andrew.lelechenko at gmail.com (Andrew Lelechenko)
Date: Sun, 31 Oct 2021 12:01:55 +0000
Subject: New CLC proposal process
In-Reply-To: <20211031094913.5oz4tczlsrh4o2h5@localhost.localdomain>
References: <6690A80D-A825-4FB5-8A6A-21078B793556@gmail.com>
 <7AA4202A-D081-4367-B5CC-DAA755419D86@posteo.de>
 <D3995316-7F6A-4B1C-8F22-F4C0FD698646@gmail.com>
 <20211031094913.5oz4tczlsrh4o2h5@localhost.localdomain>
Message-ID: <75DC6F25-6515-426B-A1F7-A188E53427A8@gmail.com>

1. On contrary, we narrowed CLC from 9 to 6 members to make it more manageable. 

2. CLC was incapable to deal with wider ecosystem issues for years. It is better not to nourish false hopes.

I believe in “Make each committee do one thing well”. CLC’s primary and undivided responsibility is `base` and, as witnessed by a huge backlog, even this single thing was handled below expectations. It’s not like we are in a good position to accept additional, wider responsibilities.

Remember that “core libraries” is an abstract moniker without much consistency: e. g., before very recent `text` was not core, and it includes `mtl`, but not `transformers`, and does not include `containers`. So AFAIU CLC was never a correct body for ecosystem-wide changes. 

(FWIW I’m hugely interested in AFPP and happy to help in my personal capacity)

Best regards,
Andrew

> On 31 Oct 2021, at 09:49, Julian Ospald <hasufell at posteo.de> wrote:
> 
> That sounds rather disappointing to me.
> 
> So what has been done to reboot the CLC is:
> 
> 1. add more people and 
> 2. narrow the scope and offload ecosystem issues to the Haskell
>   Foundation?
> 
> I've been trying to get input from the CLC for the past year on an issue
> that affects potentially all of core libraries and I don't think it's feasible
> to contact all of the maintainers isolated.
> 
> Does that mean CLC won't assist me in contacting core library
> maintainers and moderating a discussion?
> 
> 
> On Sun, Oct 31, 2021 at 12:23:57AM +0100, Andrew Lelechenko wrote:
>> As https://github.com/haskell/core-libraries-committee/blob/main/README.md
>> says, CLC owns, but does not maintain core libraries as long as they are kept
>> in order by appointed maintainers. If you find a core library abandoned and
>> neglected, raise an issue with CLC.
>> 
>> Otherwise proposals affecting core libraries should be discussed with
>> respective maintainers first. They can seek CLC opinion on controversial
>> changes, but are not obliged to. 
>> 
>> I suppose HF Tech Track could be a helpful body to ask a non-binding opinion on
>> changes with a wider scope.
>> 
>> Best regards,
>> Andrew
>> 
>> 
>>    On 31 Oct 2021, at 00:08, Julian Ospald <hasufell at posteo.de> wrote:
>> 
>>    Do I understand correctly that the CLC only governs base now?
>> 
>>    If not, where does one raise other issues that potentially affect core
>>    libraries?
>> 
>>    On October 30, 2021 8:13:18 PM UTC, Andrew Lelechenko <
>>    andrew.lelechenko at gmail.com> wrote:
>> 
>> 
>>        I'm happy to announce that Core Libraries Committee has completed
>>        post-election reboot and now has a new home at https://github.com/
>>        haskell/core-libraries-committee and a new GitHub-based process: https:
>>        //github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md.
>> 
>>        From now on proposals to change base should be raised as GitHub issues
>>        instead of emails to libraries at .
>> 
>>        Best regards,
>>        Andrew
>> 
>>