Am 21.11.21 um 19:18 schrieb Tom Ellis:

It sounds really unwise to log timestamps in anything in other than UTC. If you want to see the logged times in your local timezone then why not apply that conversion when you read the log?

UTC is wise only if you really have to deal with data originating from multiple timezones. Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something). E.g. the application I'm working with logs to text files, and it always runs in the same time zone. UTC is just an extra hoop to jump through, with no added benefit. (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.) Regards, Jo

On Sun, Nov 21, 2021 at 2:35 PM MigMit wrote:

No, non-UTC logs are a nightmare when you have developers living in different time zones. Or even in one that is different from the one where the logs come from. Not only does it still have the same overhead, but it also adds DST troubles to the mix (yes, DST does not start at the same time everywhere) and is generally MORE confusing than just having everything in UTC.

Also, editors might be fast... but only if you don't have too much logs. I did work on one project where daily logs took tens of gigabytes in gzip. Editors were out of question, trying to load this in Emacs would just hang it. Things like zgrep were pretty much the only thing that could work. Another project simply used Datadog, and was way easier to work with, despite it being a web interface.

There could be some specific cases where logging in a local time zone is a good idea, but I don't think that happens often enough.

...

On 21 Nov 2021, at 22:47, Joachim Durchholz wrote:

Am 21.11.21 um 19:18 schrieb Tom Ellis:

...

It sounds really unwise to log timestamps in anything in other than UTC. If you want to see the logged times in your local timezone then why not apply that conversion when you read the log?

UTC is wise only if you really have to deal with data originating from multiple timezones. Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something).

E.g. the application I'm working with logs to text files, and it always runs in the same time zone. UTC is just an extra hoop to jump through, with no added benefit. (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.)

Strangely, while I can see Tom's message in the archives, _I_ never received it. Anyway, it seems I did not miss anything else. Indeed, using UTC has its uses (especially when storing and/or comparing timestamps) but when viewing you definitely want to see your own TZ. Clearly, the assumption seems to be that I'm working on some enormous application supported by several teams of developers in multiple time zones that generates massive log files. While it is nice to know that my reputation is such that it is automatically assumed that I'm creating the next Google ... in reality, it's just me and I'm working on a CLI app where I want to output some log messages. ;-) So I want to see my local time in the log messages. Further research indicates that "logging" simply doesn't support my use case so I will look into writing my own wrapper around "fast-logger". P.S. What is the etiquette here: top or bottom posting? Include all participants or just the list?

The *only* messages I've seen on this thread are from MigMit. I guess at least two other people have posted, but I don't see them. Not in spam, either. Hmm On Mon, 22 Nov 2021, 0.34 MigMit, wrote:

No, non-UTC logs are a nightmare when you have developers living in different time zones. Or even in one that is different from the one where the logs come from. Not only does it still have the same overhead, but it also adds DST troubles to the mix (yes, DST does not start at the same time everywhere) and is generally MORE confusing than just having everything in UTC.

Also, editors might be fast... but only if you don't have too much logs. I did work on one project where daily logs took tens of gigabytes in gzip. Editors were out of question, trying to load this in Emacs would just hang it. Things like zgrep were pretty much the only thing that could work. Another project simply used Datadog, and was way easier to work with, despite it being a web interface.

There could be some specific cases where logging in a local time zone is a good idea, but I don't think that happens often enough.

...

On 21 Nov 2021, at 22:47, Joachim Durchholz wrote:

Am 21.11.21 um 19:18 schrieb Tom Ellis:

...

It sounds really unwise to log timestamps in anything in other than UTC. If you want to see the logged times in your local timezone then why not apply that conversion when you read the log?

UTC is wise only if you really have to deal with data originating from multiple timezones. Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something).

E.g. the application I'm working with logs to text files, and it always runs in the same time zone. UTC is just an extra hoop to jump through, with no added benefit. (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.)

Regards, Jo _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

I got at least one message from Tom Ellis in the Logging conversation, one from Joachim Durchholz, and some more. I'm definitely not included in the conversation personnally. I have no idea what might be going wrong, but I think it's not forgetting to reply to all. Cheers, Tom -------- Original Message -------- On 22 Nov 2021, 08:18, Kim-Ee Yeoh wrote:

Perhaps not gremlins in the ether but the reply button that folks hit on their web mail doesn’t include the mailing list. Hence, it wasn’t reflected to us.

Subsequently, someone in the convo noticed the absence and included haskell cafe back in. Then we see the missing messages as quoted replies.

How to fix this? Two possible approaches:

1. Remind folks to Reply to All.

2. Change the mailing list settings so that webmail reply goes to the list by default. Privatizing the convo—previously the default—is still doable. The haskell beginners list took this decision years ago.

I believe option 2 has been suggested previously.

This is a consequence of most folks migrating to webmail from unix mail clients that were a bit smarter in being able to recognize unix-driven mailing lists. (At least that’s my guess how we got here.)

On Mon, Nov 22, 2021 at 1:42 PM Bryan Richter wrote:

...

The *only* messages I've seen on this thread are from MigMit. I guess at least two other people have posted, but I don't see them. Not in spam, either. Hmm

On Mon, 22 Nov 2021, 0.34 MigMit, wrote:

...

No, non-UTC logs are a nightmare when you have developers living in different time zones. Or even in one that is different from the one where the logs come from. Not only does it still have the same overhead, but it also adds DST troubles to the mix (yes, DST does not start at the same time everywhere) and is generally MORE confusing than just having everything in UTC.

Also, editors might be fast... but only if you don't have too much logs. I did work on one project where daily logs took tens of gigabytes in gzip. Editors were out of question, trying to load this in Emacs would just hang it. Things like zgrep were pretty much the only thing that could work. Another project simply used Datadog, and was way easier to work with, despite it being a web interface.

There could be some specific cases where logging in a local time zone is a good idea, but I don't think that happens often enough.

...

On 21 Nov 2021, at 22:47, Joachim Durchholz wrote:

Am 21.11.21 um 19:18 schrieb Tom Ellis:

...

It sounds really unwise to log timestamps in anything in other than UTC. If you want to see the logged times in your local timezone then why not apply that conversion when you read the log?

UTC is wise only if you really have to deal with data originating from multiple timezones. Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something).

E.g. the application I'm working with logs to text files, and it always runs in the same time zone. UTC is just an extra hoop to jump through, with no added benefit. (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.)

Regards, Jo _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

--

-- Kim-Ee

On Mon, Nov 22, 2021 at 03:10:47AM -0500, Viktor Dukhovni wrote:

The correct DNS configuration would be:

forward zone: mta1.haskell.org. A 145.40.99.54 mta1.haskell.org. AAAA 2604:1380:4641:a100::5

reverse IPv6 zone 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR mta1.haskell.org.

reverse IPv4 zone 54.99.40.145.in-addr.arpa. PTR mta.haskell.org.

That IPv4 reverse name should of course be "mta1.haskell.org." With careful attention to the trailing dots on all FQDNs. -- Viktor.

Thanks! We're looking into this with our host. -g On Mon, Nov 22, 2021 at 3:34 AM Viktor Dukhovni wrote:

On Mon, Nov 22, 2021 at 07:33:43AM +0000, Tom Smeding wrote:

...

I got at least one message from Tom Ellis in the Logging conversation, one from Joachim Durchholz, and some more. I'm definitely not included in the conversation personnally.

I have no idea what might be going wrong, but I think it's not forgetting to reply to all.

[ TL;DR haskell.org DNS is misconfigured ]

I guess I can put my SMTP/DNS guru hat on and explain what is happening. Here's some (cryptic) data from my logs:

Nov 22 01:42:13 straasha postfix/smtpd[52426]: disconnect from unknown[145.40.99.54] ehlo=2 starttls=1 mail=1 --> rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8

Nov 22 02:19:13 straasha postfix/smtpd[52686]: disconnect from unknown[2604:1380:4641:a100::5] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

Nov 22 02:35:10 straasha postfix/smtpd[53049]: disconnect from unknown[2604:1380:4641:a100::5] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

Nov 22 02:42:51 straasha postfix/smtpd[53100]: disconnect from unknown[145.40.99.54] ehlo=2 starttls=1 mail=1 --> rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8

The first and last message were rejected: "rcpt=0/1, data=0/1" mean that "RCPT TO" and "DATA" commands were refused. The middle two messages were accepted.

The reason is DNS misconfiguration of the of mta1.haskell.org:

$ set -- mta1.haskell.org misc-services-origin-migration.haskell.org $ brief() { dig +noall +ans +nocl +nottl "$@"; } $ echo; for fwd; do brief -t a $fwd; brief -t aaaa $fwd; done

mta1.haskell.org. A 145.40.99.54

$ brief() { dig +noall +ans +nocl +nottl "$@"; } $ set -- 145.40.99.54 2604:1380:4641:a100::5 $ echo; for rev; do brief -t ptr -x $rev; done

5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR misc-services-origin-migration.haskell.org.

Only the IPv6 address has a PTR record, and even then it does not forward resolve. SMTP clients with no PTR records are routinely refused service. My mail server tolerates lack of forward mappings, but the PTR is required.

The correct DNS configuration would be:

forward zone: mta1.haskell.org. A 145.40.99.54 mta1.haskell.org. AAAA 2604:1380:4641:a100::5

reverse IPv6 zone 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR mta1.haskell.org.

reverse IPv4 zone 54.99.40.145.in-addr.arpa. PTR mta.haskell.org.

-- Viktor.

We migrated our secondary mail server, and have been working on bringing its reputation back up. As Viktor diagnosed, it also had a sending IP that did not have a PTR record, and that should now be resolved, as of last week. But I realized just now that the ptr and fwd lookup also have to correspond exactly, which they did not. That should also be now fixed. Further, I've tried to turn off sending most of our mailinglists through the secondary server, while the configuration settles down further. Apologies for the delays -- getting a proper email host set up and acquiring proper reputation is a rather expert task, and I'm far from an expert. Cheers, Gershom On Tue, Dec 7, 2021 at 11:12 PM Kim-Ee Yeoh wrote:

Mailman still isn’t reflecting all mail. Just recently, this arrived in my email:

https://mail.haskell.org/pipermail/haskell-cafe/2021-December/134940.html

But not the earlier two posts in the same thread:

https://mail.haskell.org/pipermail/haskell-cafe/2021-December/134938.html https://mail.haskell.org/pipermail/haskell-cafe/2021-December/134939.html

What has changed in the email infrastructure recently?

On Mon, Nov 22, 2021 at 10:18 PM Gershom B wrote:

...

Thanks! We're looking into this with our host.

-g

On Mon, Nov 22, 2021 at 3:34 AM Viktor Dukhovni wrote:

...

On Mon, Nov 22, 2021 at 07:33:43AM +0000, Tom Smeding wrote:

...

I got at least one message from Tom Ellis in the Logging conversation, one from Joachim Durchholz, and some more. I'm definitely not included in the conversation personnally.

I have no idea what might be going wrong, but I think it's not forgetting to reply to all.

[ TL;DR haskell.org DNS is misconfigured ]

I guess I can put my SMTP/DNS guru hat on and explain what is happening. Here's some (cryptic) data from my logs:

Nov 22 01:42:13 straasha postfix/smtpd[52426]: disconnect from unknown[145.40.99.54] ehlo=2 starttls=1 mail=1 --> rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8

Nov 22 02:19:13 straasha postfix/smtpd[52686]: disconnect from unknown[2604:1380:4641:a100::5] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

Nov 22 02:35:10 straasha postfix/smtpd[53049]: disconnect from unknown[2604:1380:4641:a100::5] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

Nov 22 02:42:51 straasha postfix/smtpd[53100]: disconnect from unknown[145.40.99.54] ehlo=2 starttls=1 mail=1 --> rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8

The first and last message were rejected: "rcpt=0/1, data=0/1" mean that "RCPT TO" and "DATA" commands were refused. The middle two messages were accepted.

The reason is DNS misconfiguration of the of mta1.haskell.org:

$ set -- mta1.haskell.org misc-services-origin-migration.haskell.org $ brief() { dig +noall +ans +nocl +nottl "$@"; } $ echo; for fwd; do brief -t a $fwd; brief -t aaaa $fwd; done

mta1.haskell.org. A 145.40.99.54

$ brief() { dig +noall +ans +nocl +nottl "$@"; } $ set -- 145.40.99.54 2604:1380:4641:a100::5 $ echo; for rev; do brief -t ptr -x $rev; done

5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR misc-services-origin-migration.haskell.org.

Only the IPv6 address has a PTR record, and even then it does not forward resolve. SMTP clients with no PTR records are routinely refused service. My mail server tolerates lack of forward mappings, but the PTR is required.

The correct DNS configuration would be:

forward zone: mta1.haskell.org. A 145.40.99.54 mta1.haskell.org. AAAA 2604:1380:4641:a100::5

reverse IPv6 zone 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR mta1.haskell.org.

reverse IPv4 zone 54.99.40.145.in-addr.arpa. PTR mta.haskell.org.

-- Viktor.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- -- Kim-Ee

Let me cite my message from another thread where messages were being lost (BTW, I fully expect you didn't receive this message originally and some of you may not receive it now; if anybody can see a particular problem with our list and a possible solution, please contact Haskell infrastructure team): On Tue, Nov 16, 2021 at 11:02 AM Mikolaj Konarski wrote:

...

I have not received your message from 4:05 PM at all, nor the message from Tom Ellis that I see at

Apparently avoiding both spam and lost emails is impossible nowadays, but I'm told the situation should improve after a recent upgrade, update of a SPF record for one of mail.haskell.org servers and gradually while our servers are regaining reputation.

For all of us on the list: let's not assume somebody that is repeating our point has seen our email --- it may have been lost or withheld for a time. Makes sense to ask for confirmation and also try to join divergent threads of the same email discussion (if the topic did not diverge).

On Sat, Nov 13, 2021 at 4:56 PM Simon Jakobi wrote:

...

Huh, I think there must be something amiss between mail.haskell.org and GMail.

I have not received your message from 4:05 PM at all, nor the message from Tom Ellis that I see at https://mail.haskell.org/pipermail/haskell-cafe/2021-November/134848.html.

Am Sa., 13. Nov. 2021 um 16:48 Uhr schrieb Mikolaj Konarski :

...

Off-topic, would it be possible to reduce the latency of mail.haskell.org?

It's quite frustrating if your message is a dupe and even more if it seems as if the other person ignored your message and wrote the stuff one again. While, in fact, the messages were 10 minutes in flight and then arrived in reverse order.

On Sat, Nov 13, 2021 at 4:05 PM Mikolaj Konarski wrote:

...

BTW, Sven, my sources say, running `haskell-ci 'github'` as opposed to `haskell-ci 'travis'` may give better results.

On Sat, Nov 13, 2021 at 2:39 PM Mikolaj Konarski wrote:

...

...

I can just offer testing haskell-ci patches etc.

Thank you. I'm sure other haskell-ci contributors can use this help, if they read this. In general, that's a great idea, supporting our developers in other ways than just code contributions, e.g., via general positivity, appreciation, goodwill, expressions of hope, uplifting user stories. They are bombarded with (impersonal) negativity all the time via bug reports.

...

The project I used as a trial balloon for haskell-ci is really dead simple, how are other projects handling this? It must be an extremely common use case, and I doubt that everybody writes the workflows by hand: This would be silly, basically all needed information is already in the .cabal file.

I'm afraid, since hvr stopped updating the PPA images (and other things), the Haskell tool ecosystem is in the very sorry and silly state you describe. Given that at this stage it's too late to help hvr, let's make sure to support Julian with ghcup (and other things) so that our ecosystem doesn't break up again, once we port haskell-ci to ghcup (if I'm guessing correctly where haskell-ci is going).

...

Other projects like e.g. lens seem to use haskell-ci successfully, see https://github.com/ekmett/lens/blob/master/.github/workflows/haskell-ci.yml. But that YAML file looks quite a bit different from what haskell-ci has generated for my project. Why?

Because it's been edited by hand for 11 months.

...

As usual, the Haskell tool ecosystem is giving me a hard time... :´-(

I sympathise.

All the best, Mikolaj

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Mon, Nov 22, 2021 at 8:38 AM Tom Smeding wrote:

I got at least one message from Tom Ellis in the Logging conversation, one from Joachim Durchholz, and some more. I'm definitely not included in the conversation personnally.

I have no idea what might be going wrong, but I think it's not forgetting to reply to all.

Cheers,

Tom

-------- Original Message -------- On 22 Nov 2021, 08:18, Kim-Ee Yeoh < ky3@atamo.com> wrote:

Perhaps not gremlins in the ether but the reply button that folks hit on their web mail doesn’t include the mailing list. Hence, it wasn’t reflected to us.

Subsequently, someone in the convo noticed the absence and included haskell cafe back in. Then we see the missing messages as quoted replies.

How to fix this? Two possible approaches:

1. Remind folks to Reply to All.

2. Change the mailing list settings so that webmail reply goes to the list by default. Privatizing the convo—previously the default—is still doable. The haskell beginners list took this decision years ago.

I believe option 2 has been suggested previously.

This is a consequence of most folks migrating to webmail from unix mail clients that were a bit smarter in being able to recognize unix-driven mailing lists. (At least that’s my guess how we got here.)

On Mon, Nov 22, 2021 at 1:42 PM Bryan Richter wrote:

...

The *only* messages I've seen on this thread are from MigMit. I guess at least two other people have posted, but I don't see them. Not in spam, either. Hmm

On Mon, 22 Nov 2021, 0.34 MigMit, wrote:

...

No, non-UTC logs are a nightmare when you have developers living in different time zones. Or even in one that is different from the one where the logs come from. Not only does it still have the same overhead, but it also adds DST troubles to the mix (yes, DST does not start at the same time everywhere) and is generally MORE confusing than just having everything in UTC.

Also, editors might be fast... but only if you don't have too much logs. I did work on one project where daily logs took tens of gigabytes in gzip. Editors were out of question, trying to load this in Emacs would just hang it. Things like zgrep were pretty much the only thing that could work. Another project simply used Datadog, and was way easier to work with, despite it being a web interface.

There could be some specific cases where logging in a local time zone is a good idea, but I don't think that happens often enough.

...

On 21 Nov 2021, at 22:47, Joachim Durchholz wrote:

Am 21.11.21 um 19:18 schrieb Tom Ellis:

...

It sounds really unwise to log timestamps in anything in other than UTC. If you want to see the logged times in your local timezone then why not apply that conversion when you read the log?

UTC is wise only if you really have to deal with data originating from multiple timezones. Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something).

E.g. the application I'm working with logs to text files, and it always runs in the same time zone. UTC is just an extra hoop to jump through, with no added benefit. (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.)

Regards, Jo _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- -- Kim-Ee _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Mon, Nov 22, 2021 at 2:38 PM Tony Zorman wrote:

On Mon, Nov 22 2021 14:18, Kim-Ee Yeoh wrote:

...

Perhaps not gremlins in the ether but the reply button that folks hit on their web mail doesn’t include the mailing list. Hence, it wasn’t reflected to us.

Subsequently, someone in the convo noticed the absence and included haskell cafe back in. Then we see the missing messages as quoted replies.

I don't think that's quite it. If you look at the thread in the list archives[1], the messages come through just fine. That wouldn't happen if people didn't at least Cc. the haskell-cafe, no?

I stand corrected then, notwithstanding what I wrote originally remainIng an extant if unrelated problem of haskell cafe until it is fixed.

(For the record, I also only got the original OP and then the latter of the two messages that MigMit sent)

[1]: https://mail.haskell.org/pipermail/haskell-cafe/2021-November/134884.html

-- -- Kim-Ee