From rae at richarde.dev  Tue Jun  1 00:05:08 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 1 Jun 2021 00:05:08 +0000
Subject: GitLab downtime
In-Reply-To: <87h7ii1wl5.fsf@smart-cactus.org>
References: <87sg24128m.fsf@smart-cactus.org>
 <87mtsb1r3l.fsf@smart-cactus.org> <87h7ii1wl5.fsf@smart-cactus.org>
Message-ID: <010f0179c4e36842-1e64cf3f-2a6d-4f59-b91c-11a3d608e723-000000@us-east-2.amazonses.com>

GitLab appears to be back up. However, access via ssh tells me

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ED25519 host key for gitlab.haskell.org has changed,
and the key for the corresponding IP address 147.75.105.243
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

This kind of error seems in keeping with the upgrade you've done, but I want explicit reassurance that I should proceed in the face of this error.

Thanks!
Richard

> On May 31, 2021, at 4:23 PM, Ben Gamari <ben at well-typed.com> wrote:
> 
> Ben Gamari <ben at well-typed.com <mailto:ben at well-typed.com>> writes:
> 
>> Ben Gamari <ben at well-typed.com> writes:
>> 
>>> Hi all,
>>> 
>>> Today I'm going to be working on migrating our GitLab instance to a new
>>> machine. Starting in likely an hour there will be a few hours of
>>> downtime while the migration proceeds. I will send an email when the
>>> downtime begins and concludes.
>>> 
>> Hi all,
>> 
>> A brief update: The GitLab downtime has not yet started as the migration
>> preparation has taken a bit longer than expected. As it is getting late,
>> I will be postponing the downtime until tomorrow evening.
>> 
>> Sorry for the inconvenience!
> 
> Hi all,
> 
> As noted yesterday I will be continue the GitLab migration starting in
> around 45 minutes. Do expect a bit of outage starting at that time.
> 
> Cheers,
> 
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210601/0175a9cb/attachment.html>

From ben at well-typed.com  Tue Jun  1 00:38:05 2021
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 31 May 2021 20:38:05 -0400
Subject: GitLab downtime
In-Reply-To: <010f0179c4e36842-1e64cf3f-2a6d-4f59-b91c-11a3d608e723-000000@us-east-2.amazonses.com>
References: <87sg24128m.fsf@smart-cactus.org>
 <87mtsb1r3l.fsf@smart-cactus.org> <87h7ii1wl5.fsf@smart-cactus.org>
 <010f0179c4e36842-1e64cf3f-2a6d-4f59-b91c-11a3d608e723-000000@us-east-2.amazonses.com>
Message-ID: <87eedm1kt2.fsf@smart-cactus.org>

Richard Eisenberg <rae at richarde.dev> writes:

> GitLab appears to be back up. However, access via ssh tells me
>
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> The ED25519 host key for gitlab.haskell.org has changed,
> and the key for the corresponding IP address 147.75.105.243
> is unknown. This could either mean that
> DNS SPOOFING is happening or the IP address for the host
> and its host key have changed at the same time.
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
>
> This kind of error seems in keeping with the upgrade you've done, but
> I want explicit reassurance that I should proceed in the face of this
> error.
>
Thanks for letting my know, Richard! You should now find that the new
box has the same SSH host key as the previous box. Let me know if you
see any other unexpected differences.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210531/37bd47af/attachment.sig>

From ben at well-typed.com  Tue Jun  1 01:01:47 2021
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 31 May 2021 21:01:47 -0400
Subject: GitLab downtime
In-Reply-To: <87sg24128m.fsf@smart-cactus.org>
References: <87sg24128m.fsf@smart-cactus.org>
Message-ID: <87bl8q1jpj.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Hi all,
>
Hi all,

I believe gitlab.haskell.org should be back up at this point. There are
still a few ancillary services (e.g. grafana.gitlab.haskell.org) that I
haven't yet validated but every critical should be functional. Do let me
know if you find anything amiss.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210531/8b39459e/attachment.sig>

From vladislav at serokell.io  Tue Jun  1 06:12:51 2021
From: vladislav at serokell.io (Vladislav Zavialov)
Date: Tue, 1 Jun 2021 09:12:51 +0300
Subject: GitLab downtime
In-Reply-To: <87bl8q1jpj.fsf@smart-cactus.org>
References: <87sg24128m.fsf@smart-cactus.org> <87bl8q1jpj.fsf@smart-cactus.org>
Message-ID: <1013B4D1-B781-46EE-908D-15A37B944809@serokell.io>

It is currently down with a 502 error.

- Vlad

> On 1 Jun 2021, at 04:01, Ben Gamari <ben at well-typed.com> wrote:
> 
> Hi all,
> 
> I believe gitlab.haskell.org should be back up at this point. There are
> still a few ancillary services (e.g. grafana.gitlab.haskell.org) that I
> haven't yet validated but every critical should be functional. Do let me
> know if you find anything amiss.
> 
> Cheers,
> 
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From shayne.fletcher.50 at gmail.com  Tue Jun  1 08:16:03 2021
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Tue, 1 Jun 2021 18:16:03 +1000
Subject: GitLab downtime
In-Reply-To: <1013B4D1-B781-46EE-908D-15A37B944809@serokell.io>
References: <87sg24128m.fsf@smart-cactus.org> <87bl8q1jpj.fsf@smart-cactus.org>
 <1013B4D1-B781-46EE-908D-15A37B944809@serokell.io>
Message-ID: <CAMsAzy-W8EWTYMBYJO8xHo-KtfadL6NRp2fY796F=1HOB9NOzw@mail.gmail.com>

Seems to be serving again now

On Tue, Jun 1, 2021 at 4:13 PM Vladislav Zavialov <vladislav at serokell.io>
wrote:

> It is currently down with a 502 error.
>
> - Vlad
>
> > On 1 Jun 2021, at 04:01, Ben Gamari <ben at well-typed.com> wrote:
> >
> > Hi all,
> >
> > I believe gitlab.haskell.org should be back up at this point. There are
> > still a few ancillary services (e.g. grafana.gitlab.haskell.org) that I
> > haven't yet validated but every critical should be functional. Do let me
> > know if you find anything amiss.
> >
> > Cheers,
> >
> > - Ben
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
Shayne Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210601/5f021afc/attachment.html>

From matthewtpickering at gmail.com  Tue Jun  1 08:19:48 2021
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 1 Jun 2021 09:19:48 +0100
Subject: GitLab downtime
In-Reply-To: <CAMsAzy-W8EWTYMBYJO8xHo-KtfadL6NRp2fY796F=1HOB9NOzw@mail.gmail.com>
References: <87sg24128m.fsf@smart-cactus.org> <87bl8q1jpj.fsf@smart-cactus.org>
 <1013B4D1-B781-46EE-908D-15A37B944809@serokell.io>
 <CAMsAzy-W8EWTYMBYJO8xHo-KtfadL6NRp2fY796F=1HOB9NOzw@mail.gmail.com>
Message-ID: <CALuQ0m-+BBnhXeZdGTG6xePF0J1Rw7mTsW8H5GguhmaNEtqYFQ@mail.gmail.com>

I restarted the service but somethings still appear to be broken.

On Tue, Jun 1, 2021 at 9:16 AM Shayne Fletcher
<shayne.fletcher.50 at gmail.com> wrote:
>
> Seems to be serving again now
>
> On Tue, Jun 1, 2021 at 4:13 PM Vladislav Zavialov <vladislav at serokell.io> wrote:
>>
>> It is currently down with a 502 error.
>>
>> - Vlad
>>
>> > On 1 Jun 2021, at 04:01, Ben Gamari <ben at well-typed.com> wrote:
>> >
>> > Hi all,
>> >
>> > I believe gitlab.haskell.org should be back up at this point. There are
>> > still a few ancillary services (e.g. grafana.gitlab.haskell.org) that I
>> > haven't yet validated but every critical should be functional. Do let me
>> > know if you find anything amiss.
>> >
>> > Cheers,
>> >
>> > - Ben
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> --
> Shayne Fletcher
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From rae at richarde.dev  Tue Jun  1 21:34:57 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 1 Jun 2021 21:34:57 +0000
Subject: value of documenting error messages?
Message-ID: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>

Hi devs,

Take a quick look at https://gitlab.haskell.org/ghc/ghc/-/blob/6db8a0f76ec45d47060e28bb303e9eef60bdb16b/compiler/GHC/Driver/Errors/Types.hs#L107 <https://gitlab.haskell.org/ghc/ghc/-/blob/6db8a0f76ec45d47060e28bb303e9eef60bdb16b/compiler/GHC/Driver/Errors/Types.hs#L107>  You will see a datatype there with constructors describing error messages that GHC might produce. These constructors have comments describing the error, sometimes giving an example, and sometimes listing test cases. More datatypes like this one and more constructors in these datatypes are on the way.

Question: Is there sufficient value in carefully documenting each constructor?

In my ideal world, each constructor would have a high-level description, a detailed description of each field, an example of a program that generates the error, and one or more test cases that test the output. Along the way, we might discover that no such test case exists, and then we would add. However, generating this documentation is hard. I was thinking of whipping up an army of volunteers (Hécate has advised me how to do this) to do the work, but that army will need to be fed (with instructions, supervision, and reviews) and will want to know that their work is important. Is this effort worthwhile? Do we see ourselves maintaining this documentation? Or is the effort better spent elsewhere, perhaps tagging each constructor with an ID and then making wiki pages? Not sure what's best -- would love ideas!

Credit to Alfredo di Napoli, who's done the heavy lifting of getting us this far.

Relevant tickets: 
Original: https://gitlab.haskell.org/ghc/ghc/-/issues/18516
Tasks left: https://gitlab.haskell.org/ghc/ghc/-/issues/19905

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210601/a9a38128/attachment.html>

From alec.theriault at gmail.com  Tue Jun  1 22:40:57 2021
From: alec.theriault at gmail.com (Alec Theriault)
Date: Tue, 1 Jun 2021 15:40:57 -0700
Subject: value of documenting error messages?
In-Reply-To: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
Message-ID: <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>

Hello,

If these are the messages that get pretty-printed into errors or warnings,
I would think detailed documentation is definitely useful. However, since
this is documentation that users of GHC will want to read (and not just
contributors), I think it should live primarily in the user's guide and not
the Haddocks.

Rust has taken an interesting approach for this: every error message is
given a unique number like "E0119" and there is an error index
<https://doc.rust-lang.org/error-index.html#E0119> generated from simple
markdown files
<https://github.com/rust-lang/rust/tree/master/compiler/rustc_error_codes/src/error_codes>
containing explanations and examples for the errors (error codes by
themselves already massively help searchability). If GHC were to take this
approach, I think it would be fine to just include the error message
identifier in the Haddocks.

Alec

PS: Rust even bundles the documentation for errors into the compiler, so
you can do something like `rustc --explain E0119` to get the full
description of the error. It'd be pretty neat if GHC could do this too.
Some errors don't have much to say about them, but others definitely could
be explained!

On Tue, Jun 1, 2021 at 2:36 PM Richard Eisenberg <rae at richarde.dev> wrote:

> Hi devs,
>
> Take a quick look at
> https://gitlab.haskell.org/ghc/ghc/-/blob/6db8a0f76ec45d47060e28bb303e9eef60bdb16b/compiler/GHC/Driver/Errors/Types.hs#L107
> You will see a datatype there with constructors describing error messages
> that GHC might produce. These constructors have comments describing the
> error, sometimes giving an example, and sometimes listing test cases. More
> datatypes like this one and more constructors in these datatypes are on the
> way.
>
> Question: Is there sufficient value in carefully documenting each
> constructor?
>
> In my ideal world, each constructor would have a high-level description, a
> detailed description of each field, an example of a program that generates
> the error, and one or more test cases that test the output. Along the way,
> we might discover that no such test case exists, and then we would add.
> However, generating this documentation is hard. I was thinking of whipping
> up an army of volunteers (Hécate has advised me how to do this) to do the
> work, but that army will need to be fed (with instructions, supervision,
> and reviews) and will want to know that their work is important. Is this
> effort worthwhile? Do we see ourselves maintaining this documentation? Or
> is the effort better spent elsewhere, perhaps tagging each constructor with
> an ID and then making wiki pages? Not sure what's best -- would love ideas!
>
> Credit to Alfredo di Napoli, who's done the heavy lifting of getting us
> this far.
>
> Relevant tickets:
> Original: https://gitlab.haskell.org/ghc/ghc/-/issues/18516
> Tasks left: https://gitlab.haskell.org/ghc/ghc/-/issues/19905
>
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210601/958c2ae7/attachment.html>

From baldurpet at gmail.com  Tue Jun  1 23:01:24 2021
From: baldurpet at gmail.com (=?UTF-8?Q?Baldur_Bl=C3=B6ndal?=)
Date: Wed, 2 Jun 2021 00:01:24 +0100
Subject: Give MonadTrans a QuantifiedConstraints superclass
Message-ID: <CAK9DwL990PMbOFVMimrX2PxtL260AUk547sC9nBKEKT4NJqLaQ@mail.gmail.com>

This is to advertise the proposal
(https://gitlab.haskell.org/ghc/ghc/-/issues/19922) to add a
superclass to the MonadTrans type class in Control.Monad.Trans.

A Monad transformer 'trans' lifts a 'Monad m' to a 'Monad (trans m)'.

This proposal code-ifies that with a superclass constraint, an
impliciation constraint enabled by the recent extension
QuantifiedConstraints:

    class (forall m. Monad m => Monad (trans m)) => MonadTrans trans where
      ..

This is the main motiviating example of the Quantified Class
Constraints paper https://gkaracha.github.io/papers/quantcs.pdf

From chessai1996 at gmail.com  Tue Jun  1 23:40:13 2021
From: chessai1996 at gmail.com (chessai)
Date: Tue, 1 Jun 2021 18:40:13 -0500
Subject: Give MonadTrans a QuantifiedConstraints superclass
In-Reply-To: <CAK9DwL990PMbOFVMimrX2PxtL260AUk547sC9nBKEKT4NJqLaQ@mail.gmail.com>
References: <CAK9DwL990PMbOFVMimrX2PxtL260AUk547sC9nBKEKT4NJqLaQ@mail.gmail.com>
Message-ID: <CAD34_k+c1-s1gVby8GNrZ5ay+Ur7N7Mqu-=mZP_7=UEApDSiHw@mail.gmail.com>

I think you meant to forward to the libraries mailing list, not the
ghc-devs one

On Tue, Jun 1, 2021, 18:01 Baldur Blöndal <baldurpet at gmail.com> wrote:

> This is to advertise the proposal
> (https://gitlab.haskell.org/ghc/ghc/-/issues/19922) to add a
> superclass to the MonadTrans type class in Control.Monad.Trans.
>
> A Monad transformer 'trans' lifts a 'Monad m' to a 'Monad (trans m)'.
>
> This proposal code-ifies that with a superclass constraint, an
> impliciation constraint enabled by the recent extension
> QuantifiedConstraints:
>
>     class (forall m. Monad m => Monad (trans m)) => MonadTrans trans where
>       ..
>
> This is the main motiviating example of the Quantified Class
> Constraints paper https://gkaracha.github.io/papers/quantcs.pdf
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210601/da99fa74/attachment.html>

From giorgio at marinel.li  Wed Jun  2 04:26:26 2021
From: giorgio at marinel.li (Giorgio Marinelli)
Date: Wed, 2 Jun 2021 06:26:26 +0200
Subject: GitLab downtime
In-Reply-To: <CALuQ0m-+BBnhXeZdGTG6xePF0J1Rw7mTsW8H5GguhmaNEtqYFQ@mail.gmail.com>
References: <87sg24128m.fsf@smart-cactus.org> <87bl8q1jpj.fsf@smart-cactus.org>
 <1013B4D1-B781-46EE-908D-15A37B944809@serokell.io>
 <CAMsAzy-W8EWTYMBYJO8xHo-KtfadL6NRp2fY796F=1HOB9NOzw@mail.gmail.com>
 <CALuQ0m-+BBnhXeZdGTG6xePF0J1Rw7mTsW8H5GguhmaNEtqYFQ@mail.gmail.com>
Message-ID: <CAG6_cxYSbS54uHoRAnOfHcCs+ieirwG_v1MjTVcMyZ7ojoB=aQ@mail.gmail.com>

502 again.


Giorgio


On Tue, 1 Jun 2021 at 10:20, Matthew Pickering
<matthewtpickering at gmail.com> wrote:
>
> I restarted the service but somethings still appear to be broken.
>
> On Tue, Jun 1, 2021 at 9:16 AM Shayne Fletcher
> <shayne.fletcher.50 at gmail.com> wrote:
> >
> > Seems to be serving again now
> >
> > On Tue, Jun 1, 2021 at 4:13 PM Vladislav Zavialov <vladislav at serokell.io> wrote:
> >>
> >> It is currently down with a 502 error.
> >>
> >> - Vlad
> >>
> >> > On 1 Jun 2021, at 04:01, Ben Gamari <ben at well-typed.com> wrote:
> >> >
> >> > Hi all,
> >> >
> >> > I believe gitlab.haskell.org should be back up at this point. There are
> >> > still a few ancillary services (e.g. grafana.gitlab.haskell.org) that I
> >> > haven't yet validated but every critical should be functional. Do let me
> >> > know if you find anything amiss.
> >> >
> >> > Cheers,
> >> >
> >> > - Ben
> >> > _______________________________________________
> >> > ghc-devs mailing list
> >> > ghc-devs at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> >
> > --
> > Shayne Fletcher
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ben at well-typed.com  Wed Jun  2 04:40:43 2021
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 02 Jun 2021 00:40:43 -0400
Subject: GitLab downtime
In-Reply-To: <CAG6_cxYSbS54uHoRAnOfHcCs+ieirwG_v1MjTVcMyZ7ojoB=aQ@mail.gmail.com>
References: <87sg24128m.fsf@smart-cactus.org> <87bl8q1jpj.fsf@smart-cactus.org>
 <1013B4D1-B781-46EE-908D-15A37B944809@serokell.io>
 <CAMsAzy-W8EWTYMBYJO8xHo-KtfadL6NRp2fY796F=1HOB9NOzw@mail.gmail.com>
 <CALuQ0m-+BBnhXeZdGTG6xePF0J1Rw7mTsW8H5GguhmaNEtqYFQ@mail.gmail.com>
 <CAG6_cxYSbS54uHoRAnOfHcCs+ieirwG_v1MjTVcMyZ7ojoB=aQ@mail.gmail.com>
Message-ID: <CAF5248E-4DFD-425C-AA83-7716D1504400@well-typed.com>

It looks like this is the result of the recurrence of a nixpkgs issue. I have applied a potential workaround.

Cheers,

- Ben 

On June 2, 2021 12:26:26 AM EDT, Giorgio Marinelli <giorgio at marinel.li> wrote:
>502 again.
>
>
>Giorgio
>
>
>On Tue, 1 Jun 2021 at 10:20, Matthew Pickering
><matthewtpickering at gmail.com> wrote:
>>
>> I restarted the service but somethings still appear to be broken.
>>
>> On Tue, Jun 1, 2021 at 9:16 AM Shayne Fletcher
>> <shayne.fletcher.50 at gmail.com> wrote:
>> >
>> > Seems to be serving again now
>> >
>> > On Tue, Jun 1, 2021 at 4:13 PM Vladislav Zavialov
><vladislav at serokell.io> wrote:
>> >>
>> >> It is currently down with a 502 error.
>> >>
>> >> - Vlad
>> >>
>> >> > On 1 Jun 2021, at 04:01, Ben Gamari <ben at well-typed.com> wrote:
>> >> >
>> >> > Hi all,
>> >> >
>> >> > I believe gitlab.haskell.org should be back up at this point.
>There are
>> >> > still a few ancillary services (e.g. grafana.gitlab.haskell.org)
>that I
>> >> > haven't yet validated but every critical should be functional.
>Do let me
>> >> > know if you find anything amiss.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > - Ben
>> >> > _______________________________________________
>> >> > ghc-devs mailing list
>> >> > ghc-devs at haskell.org
>> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>
>> >> _______________________________________________
>> >> ghc-devs mailing list
>> >> ghc-devs at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>> >
>> >
>> > --
>> > Shayne Fletcher
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>_______________________________________________
>ghc-devs mailing list
>ghc-devs at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210602/147cf1a8/attachment.html>

From simonpj at microsoft.com  Wed Jun  2 10:25:44 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 2 Jun 2021 10:25:44 +0000
Subject: value of documenting error messages?
In-Reply-To: <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
Message-ID: <AM5PR83MB03530FF1934E1C39BF3F6461AD3D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>

Rust has taken an interesting approach for this: every error message is given a unique number like "E0119" and there is an error index<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.rust-lang.org%2Ferror-index.html%23E0119&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865456276%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fNrQBjAVF2CrG5tCZYTGg0DVIOxRszYNp49ixg%2F4%2FX0%3D&reserved=0> generated from simple markdown files<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frust-lang%2Frust%2Ftree%2Fmaster%2Fcompiler%2Frustc_error_codes%2Fsrc%2Ferror_codes&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865466273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=m6m4y%2BbabeAbLf0X7l%2FYGRo7qvqYQu1W0onZ8k7uBYI%3D&reserved=0> containing explanations and examples for the errors (error codes by themselves already massively help searchability). If GHC were to take this approach, I think it would be fine to just include the error message identifier in the Haddocks.

I think this is a great idea, including that of giving unique numbers.

We should be aware that there are two client groups:

  1.  Users, for whom the error index above is ideal
  2.  Clients of the GHC API (e.g. authors of an IDE) who are consuming the data type itself, and need to know what the various fields mean.

For (A) the Rust approach seems terrific.

For (B) adding Haddocks as in the example Richard gave seems better.  But it should not repeat (A); rather it should assume you are also looking at (A) for that error number, and add any implementation specific info, like what the fields mean, and what the test cases are.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Alec Theriault
Sent: 01 June 2021 23:41
To: Richard Eisenberg <rae at richarde.dev>
Cc: GHC developers <ghc-devs at haskell.org>
Subject: Re: value of documenting error messages?

Hello,

If these are the messages that get pretty-printed into errors or warnings, I would think detailed documentation is definitely useful. However, since this is documentation that users of GHC will want to read (and not just contributors), I think it should live primarily in the user's guide and not the Haddocks.

Rust has taken an interesting approach for this: every error message is given a unique number like "E0119" and there is an error index<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.rust-lang.org%2Ferror-index.html%23E0119&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865456276%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fNrQBjAVF2CrG5tCZYTGg0DVIOxRszYNp49ixg%2F4%2FX0%3D&reserved=0> generated from simple markdown files<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frust-lang%2Frust%2Ftree%2Fmaster%2Fcompiler%2Frustc_error_codes%2Fsrc%2Ferror_codes&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865466273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=m6m4y%2BbabeAbLf0X7l%2FYGRo7qvqYQu1W0onZ8k7uBYI%3D&reserved=0> containing explanations and examples for the errors (error codes by themselves already massively help searchability). If GHC were to take this approach, I think it would be fine to just include the error message identifier in the Haddocks.

Alec

PS: Rust even bundles the documentation for errors into the compiler, so you can do something like `rustc --explain E0119` to get the full description of the error. It'd be pretty neat if GHC could do this too. Some errors don't have much to say about them, but others definitely could be explained!

On Tue, Jun 1, 2021 at 2:36 PM Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:
Hi devs,

Take a quick look at https://gitlab.haskell.org/ghc/ghc/-/blob/6db8a0f76ec45d47060e28bb303e9eef60bdb16b/compiler/GHC/Driver/Errors/Types.hs#L107<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fblob%2F6db8a0f76ec45d47060e28bb303e9eef60bdb16b%2Fcompiler%2FGHC%2FDriver%2FErrors%2FTypes.hs%23L107&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865466273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kXIh0I3JZObTbB8Huki5EHFaPGHNcjcYBKxpBpfeqNM%3D&reserved=0>  You will see a datatype there with constructors describing error messages that GHC might produce. These constructors have comments describing the error, sometimes giving an example, and sometimes listing test cases. More datatypes like this one and more constructors in these datatypes are on the way.

Question: Is there sufficient value in carefully documenting each constructor?

In my ideal world, each constructor would have a high-level description, a detailed description of each field, an example of a program that generates the error, and one or more test cases that test the output. Along the way, we might discover that no such test case exists, and then we would add. However, generating this documentation is hard. I was thinking of whipping up an army of volunteers (Hécate has advised me how to do this) to do the work, but that army will need to be fed (with instructions, supervision, and reviews) and will want to know that their work is important. Is this effort worthwhile? Do we see ourselves maintaining this documentation? Or is the effort better spent elsewhere, perhaps tagging each constructor with an ID and then making wiki pages? Not sure what's best -- would love ideas!

Credit to Alfredo di Napoli, who's done the heavy lifting of getting us this far.

Relevant tickets:
Original: https://gitlab.haskell.org/ghc/ghc/-/issues/18516<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F18516&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865476267%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xy2lUIjOwAtV%2BjZajPytLyyiy3f94xIulkTt8tHAF5g%3D&reserved=0>
Tasks left: https://gitlab.haskell.org/ghc/ghc/-/issues/19905<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F19905&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865476267%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mJHN1JSv5lvCdByhLpwzGwgnGOCKGY7Oej2UbYvFttI%3D&reserved=0>

Thanks,
Richard
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865486259%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3dZA9c6ZPotW0A89KIvEVyuXkB0tfRJVU6uUGVgZwik%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210602/1e8d39c9/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Jun  2 10:46:14 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 2 Jun 2021 11:46:14 +0100
Subject: value of documenting error messages?
In-Reply-To: <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
Message-ID: <20210602104614.GP27384@cloudinit-builder>

On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec Theriault wrote:
> Rust has taken an interesting approach for this: every error message is
> given a unique number like "E0119"

Is there a particularly strong reason to use numbers as codes when we
have the entire space human-readable strings available to us?  Even
the subset of case-insensitive strings formed from alphanumeric
characters plus underscore seems more suitable for the encoding than
positive integers.

e.g. "conflicting_trait_implementations" seems better than "E0119"

Tom

From ruben.astud at gmail.com  Wed Jun  2 15:22:47 2021
From: ruben.astud at gmail.com (Ruben Astudillo)
Date: Wed, 2 Jun 2021 11:22:47 -0400
Subject: value of documenting error messages?
In-Reply-To: <20210602104614.GP27384@cloudinit-builder>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
Message-ID: <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>

I am no GHC developer, so this is not my place to reply. Even though I
humbly would like to put an argument in favor of numbers.

On 02-06-21 06:46, Tom Ellis wrote:
> On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec Theriault wrote:
>> Rust has taken an interesting approach for this: every error message is
>> given a unique number like "E0119"
> 
> Is there a particularly strong reason to use numbers as codes when we
> have the entire space human-readable strings available to us?  Even
> the subset of case-insensitive strings formed from alphanumeric
> characters plus underscore seems more suitable for the encoding than
> positive integers.
> 
> e.g. "conflicting_trait_implementations" seems better than "E0119"

One is SEO-optimization. A number like #0119 on a search string like "ghc
error #0119" ought to have as a first result the GHC user docs. This is a
great user experience for students. A more general search string can have
more results on other languages and is difficult to say we would be first
result.

Second one is that a number is shorter than a general string. That way we
can highlight it on a error message on the terminal without occupying to
much space. Current messages in GHC are already too big.

-- 
-- Rubén
-- pgp: 4EE9 28F7 932E F4AD

From carter.schonwald at gmail.com  Wed Jun  2 16:12:17 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 2 Jun 2021 12:12:17 -0400
Subject: value of documenting error messages?
In-Reply-To: <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
 <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
Message-ID: <CAHYVw0zGLn9L0eSCnmVH1+9S58qDzwTfgzJdEUOGyn_9y=MN8Q@mail.gmail.com>

And just generally having a short code and descriptive name both, allows
useful toooling and human communication.

If we want to be careful / hedge against errors/ warnings  being slightly
different over time, these descriptive names / error codes should also be
documented with respect to the ghc version being used.

For example, I  remember in ghc 8.2 or so for example that for certain type
family uses that were actually fine that ghc would warn that allow
ambiguous types.  Richard may recall this better than I.  The important
piece is that in at least some cases, the full meaning and interpretation
of various warnings has definitely changed over ghc versions as various
analyses get fancier or simpler or bug fixed.

So in some respects, at least historically: for sufficiently fancy code,
the context of meaning for a given error code / message will only be
unambiguous if we interpret it knowing the specific ghc version.

I presume this will still be true? Should we always talk about error code
ghc version pairs rather than error codes? If so should the error rendering
be like ghc9_4_1:E2433 as a sortah URI ?

On Wed, Jun 2, 2021 at 11:24 AM Ruben Astudillo <ruben.astud at gmail.com>
wrote:

> I am no GHC developer, so this is not my place to reply. Even though I
> humbly would like to put an argument in favor of numbers.
>
> On 02-06-21 06:46, Tom Ellis wrote:
> > On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec Theriault wrote:
> >> Rust has taken an interesting approach for this: every error message is
> >> given a unique number like "E0119"
> >
> > Is there a particularly strong reason to use numbers as codes when we
> > have the entire space human-readable strings available to us?  Even
> > the subset of case-insensitive strings formed from alphanumeric
> > characters plus underscore seems more suitable for the encoding than
> > positive integers.
> >
> > e.g. "conflicting_trait_implementations" seems better than "E0119"
>
> One is SEO-optimization. A number like #0119 on a search string like "ghc
> error #0119" ought to have as a first result the GHC user docs. This is a
> great user experience for students. A more general search string can have
> more results on other languages and is difficult to say we would be first
> result.
>
> Second one is that a number is shorter than a general string. That way we
> can highlight it on a error message on the terminal without occupying to
> much space. Current messages in GHC are already too big.
>
> --
> -- Rubén
> -- pgp: 4EE9 28F7 932E F4AD
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210602/11d6c50f/attachment.html>

From mcarneir at andrew.cmu.edu  Wed Jun  2 16:25:18 2021
From: mcarneir at andrew.cmu.edu (Mario Carneiro)
Date: Wed, 2 Jun 2021 12:25:18 -0400
Subject: value of documenting error messages?
In-Reply-To: <CAHYVw0zGLn9L0eSCnmVH1+9S58qDzwTfgzJdEUOGyn_9y=MN8Q@mail.gmail.com>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
 <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
 <CAHYVw0zGLn9L0eSCnmVH1+9S58qDzwTfgzJdEUOGyn_9y=MN8Q@mail.gmail.com>
Message-ID: <CAFXXJSuwt091buxyLEWLbiU6iQPYOWzA0KWp4PJ45BePJV4Jew@mail.gmail.com>

Rust error codes are not sequential, presumably because some old errors are
no longer applicable and new errors get new numbers. It seems to me that it
should be possible to just allocate numbers so that if the error changes
more than cosmetically then it gets a new number, and thus the error code
alone should be sufficient. If a new GHC version changes the meaning of an
error message, it should drop the old error code and allocate a new one, so
as not to confuse searchers.

On Wed, Jun 2, 2021 at 12:13 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> And just generally having a short code and descriptive name both, allows
> useful toooling and human communication.
>
> If we want to be careful / hedge against errors/ warnings  being slightly
> different over time, these descriptive names / error codes should also be
> documented with respect to the ghc version being used.
>
> For example, I  remember in ghc 8.2 or so for example that for certain
> type family uses that were actually fine that ghc would warn that allow
> ambiguous types.  Richard may recall this better than I.  The important
> piece is that in at least some cases, the full meaning and interpretation
> of various warnings has definitely changed over ghc versions as various
> analyses get fancier or simpler or bug fixed.
>
> So in some respects, at least historically: for sufficiently fancy code,
> the context of meaning for a given error code / message will only be
> unambiguous if we interpret it knowing the specific ghc version.
>
> I presume this will still be true? Should we always talk about error code
> ghc version pairs rather than error codes? If so should the error rendering
> be like ghc9_4_1:E2433 as a sortah URI ?
>
> On Wed, Jun 2, 2021 at 11:24 AM Ruben Astudillo <ruben.astud at gmail.com>
> wrote:
>
>> I am no GHC developer, so this is not my place to reply. Even though I
>> humbly would like to put an argument in favor of numbers.
>>
>> On 02-06-21 06:46, Tom Ellis wrote:
>> > On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec Theriault wrote:
>> >> Rust has taken an interesting approach for this: every error message is
>> >> given a unique number like "E0119"
>> >
>> > Is there a particularly strong reason to use numbers as codes when we
>> > have the entire space human-readable strings available to us?  Even
>> > the subset of case-insensitive strings formed from alphanumeric
>> > characters plus underscore seems more suitable for the encoding than
>> > positive integers.
>> >
>> > e.g. "conflicting_trait_implementations" seems better than "E0119"
>>
>> One is SEO-optimization. A number like #0119 on a search string like "ghc
>> error #0119" ought to have as a first result the GHC user docs. This is a
>> great user experience for students. A more general search string can have
>> more results on other languages and is difficult to say we would be first
>> result.
>>
>> Second one is that a number is shorter than a general string. That way we
>> can highlight it on a error message on the terminal without occupying to
>> much space. Current messages in GHC are already too big.
>>
>> --
>> -- Rubén
>> -- pgp: 4EE9 28F7 932E F4AD
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210602/0047329a/attachment.html>

From simonpj at microsoft.com  Wed Jun  2 16:46:06 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 2 Jun 2021 16:46:06 +0000
Subject: value of documenting error messages?
In-Reply-To: <20210602104614.GP27384@cloudinit-builder>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
Message-ID: <AM5PR83MB0353B38858407F202F184230AD3D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>

|  e.g. "conflicting_trait_implementations" seems better than "E0119"

I don't think so.  If the compiler prints "E0119" and I search for that, I know I'm going to get exactly that, not similar but subtly different things. (A free text search might also throw up illuminating info, but is much less precise.)

Simon

|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Tom Ellis
|  Sent: 02 June 2021 11:46
|  To: ghc-devs at haskell.org
|  Subject: Re: value of documenting error messages?
|  
|  On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec Theriault wrote:
|  > Rust has taken an interesting approach for this: every error message
|  > is given a unique number like "E0119"
|  
|  Is there a particularly strong reason to use numbers as codes when we have
|  the entire space human-readable strings available to us?  Even the subset of
|  case-insensitive strings formed from alphanumeric characters plus underscore
|  seems more suitable for the encoding than positive integers.
|  
|  e.g. "conflicting_trait_implementations" seems better than "E0119"
|  
|  Tom
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel
|  l.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C746c7987d166423f0cf808d925
|  b3da91%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637582277123771646%7CUnk
|  nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
|  CI6Mn0%3D%7C2000&amp;sdata=ymgTrD0iPgl7%2Bf%2FOLwOP6r%2BJGfkiR2ej0QQl0oig2Pk
|  %3D&amp;reserved=0

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Jun  2 17:49:21 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 2 Jun 2021 18:49:21 +0100
Subject: value of documenting error messages?
In-Reply-To: <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
 <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
Message-ID: <20210602174921.GQ27384@cloudinit-builder>

On Wed, Jun 02, 2021 at 11:22:47AM -0400, Ruben Astudillo wrote:
> I am no GHC developer, so this is not my place to reply. Even though I
> humbly would like to put an argument in favor of numbers.

The issue of error codes impinges more on GHC users than GHC
developers (although it's also a bit tangential to Richard's original
post).

> On 02-06-21 06:46, Tom Ellis wrote:
> > On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec Theriault wrote:
> >> Rust has taken an interesting approach for this: every error message is
> >> given a unique number like "E0119"
> > 
> > Is there a particularly strong reason to use numbers as codes when we
> > have the entire space human-readable strings available to us?  Even
> > the subset of case-insensitive strings formed from alphanumeric
> > characters plus underscore seems more suitable for the encoding than
> > positive integers.
> > 
> > e.g. "conflicting_trait_implementations" seems better than "E0119"
> 
> One is SEO-optimization. A number like #0119 on a search string like "ghc
> error #0119" ought to have as a first result the GHC user docs. This is a
> great user experience for students. A more general search string can have
> more results on other languages and is difficult to say we would be first
> result.
> 
> Second one is that a number is shorter than a general string. That way we
> can highlight it on a error message on the terminal without occupying to
> much space. Current messages in GHC are already too big.

I'm surprised by the responses to the idea of descriptive error codes
(not just Ruben's response).

"ghc error #0119" seems like no better a search string than "ghc error
conflicting_trait_implementations" (and I can concoct reasons why it
would be worse).  Non-descriptive error codes risk being buried in
results about food additives[1] amongst myriad other things.

If we really think that non-descriptive codes are the clearest way to
communicate between machines and humans then I wonder if we should
rename `mapAccumL` to `F392` and `TypeFamilies` to `X56`.

Tom

[1] https://en.wikipedia.org/wiki/E_number#Full_list

From rae at richarde.dev  Wed Jun  2 18:13:17 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 2 Jun 2021 18:13:17 +0000
Subject: value of documenting error messages?
In-Reply-To: <20210602174921.GQ27384@cloudinit-builder>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
 <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
 <20210602174921.GQ27384@cloudinit-builder>
Message-ID: <010f0179cdedffd6-f1bb68b3-f8bd-4987-a5e2-d5312360e3f2-000000@us-east-2.amazonses.com>

I'm in favor of short, undescriptive, quite-possibly numeric error codes.

Advantages:
* Easy to sequentialize. We might have, for example, a "conflicting_trait_implementations" from this year, move on from that design, and then accidentally reintroduce it in a decade, to confusion. Along similar lines, it is easy to write in a comment somewhere what the next error code should be, without having to search the codebase for a use.
* Easy to make compositional. We can choose to have all GHC error codes begin with G (for GHC). Then Cabal could use C, Haddock could use H, and Stack could use S. This makes it easy for users to tell (once they've learned the scheme) where an error has come from.
* Short.
* No chance for misspellings during transcription. When I'm copying a terse identifier, I know I have to get every glyph correct. If I remember that the error code is "bad_generalizing", I might not know how "generalizing" is spelled. I might also forget whether it's "generalizing" or "generalization". And I could very easily see myself making either both of these mistakes as I'm switching from one window to another, in under a second.

Disadvantages:
* The code does not impart semantic meaning. But I argue this is not so bad, as even a more descriptive code does not impart a precise enough semantic meaning to be helpful.

> On Jun 2, 2021, at 1:49 PM, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> 
> If we really think that non-descriptive codes are the clearest way to
> communicate between machines and humans then I wonder if we should
> rename `mapAccumL` to `F392` and `TypeFamilies` to `X56`.

I think this is a false equivalence. The error codes are meant to be looked up when you see them on your screen, not remembered and then produced at will.

-------

Surfacing up a few levels: it sounds like a good next step is not to get all these constructors finely documented, but instead to come up with a way to connect these constructors to user-facing documentation. This might be done by slurping out Markdown from the GHC source code, or perhaps something better. It would be a shame to invest a lot of effort in documenting the constructors in a way that serves only GHC developers, not end users, when we can perhaps do both at the same time.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210602/5ce5bbfa/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Jun  2 18:48:11 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 2 Jun 2021 19:48:11 +0100
Subject: value of documenting error messages?
In-Reply-To: <010f0179cdedffd6-f1bb68b3-f8bd-4987-a5e2-d5312360e3f2-000000@us-east-2.amazonses.com>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
 <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
 <20210602174921.GQ27384@cloudinit-builder>
 <010f0179cdedffd6-f1bb68b3-f8bd-4987-a5e2-d5312360e3f2-000000@us-east-2.amazonses.com>
Message-ID: <20210602184811.GI4204@cloudinit-builder>

On Wed, Jun 02, 2021 at 06:13:17PM +0000, Richard Eisenberg wrote:
> I'm in favor of short, undescriptive, quite-possibly numeric error
> codes.

These responses are so completely opposite to what I expected that I
can't help thinking I've made a fundamental error in my understanding
of what we're trying to achieve!  Since no one has suggested any
support for the idea of descriptive error codes I'm pressing on mostly
in the hope that someone will be able to see from where my
misunderstanding arises and set me straight.

Before I continue, I'd like to suggest that this is very much a
user-facing issue and I would be strongly in favour of actually asking
users about what they prefer (and allowing them to discuss for a
while) rather than taking a straw poll amongst GHC developers.

To that end, would it be inappropriate of me to link this discussion
to Haskell Reddit and/or Haskell Discourse?

> Advantages:

> Easy to sequentialize. We might have, for example, a
> "conflicting_trait_implementations" from this year, move on from
> that design, and then accidentally reintroduce it in a decade, to
> confusion. Along similar lines, it is easy to write in a comment
> somewherewhat the next error code should be, without having to
> search the codebase for a use.

I don't understand at all why it's valuable to sequentialize.  Is the
relative ordering of error codes meaningful in some way?

I don't see why deprecating an error code and reintroducing it is a
problem any more than doing the same to a function or GHC extension.

If we are *really* desperate to disambiguate then
conflicting_trait_implementations_2021 still seems better to me than
E195.

> Easy to make compositional. We can choose to have all GHC error
> codes begin with G (for GHC). Then Cabal could use C, Haddock could
> use H, and Stack could use S. This makes it easy for users to tell
> (once they've learned the scheme) where an error has come from.

Surely the same holds for descriptive error codes.  One could have
G_conflicting_trait_implementations, H_malformatted_section_header,
...

> Short.

Again I must be misunderstanding.  Why is brevity valuable?  Aren't we
expecting users to read these things and look them up?  Copy/paste is
free.

> No chance for misspellings during transcription. When I'm copying a
> terse identifier, I know I have to get every glyph correct. If I
> remember that the error code is "bad_generalizing", I might not know
> how "generalizing" is spelled. I might also forget whether it's
> "generalizing" or "generalization". And I could very easily see
> myself making either both of these mistakes as I'm switching from
> one window to another, in under a second.

Surely it's just as easy to mistype E159 as E195 as it is to misspell
"generalise".  As above, copy/paste is free and if we *really* want to
be helpful then instead of naked error codes we should give URLs whch
directly link to sections in the GHC users guide (or other appropriate
resource).

> Disadvantages:

> The code does not impart semantic meaning. But I argue this is not
> so bad, as even a more descriptive code does not impart a precise
> enough semantic meaning to be helpful.

I challenge you to name your next GHC extension X25!

> > On Jun 2, 2021, at 1:49 PM, Tom Ellis
> > <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> >
> > If we really think that non-descriptive codes are the clearest way
> > to communicate between machines and humans then I wonder if we
> > should rename `mapAccumL` to `F392` and `TypeFamilies` to `X56`.
>
> I think this is a false equivalence. The error codes are meant to be
> looked up when you see them on your screen, not remembered and then
> produced at will.

Possibly ... possibly not.

"Hey Anna, what should I do about E159?"

"Hey Anna, what should I do about conflicting_trait_implementations?"

Which would I prefer to shout to my colleague across the room?


To me this seems like a rare opportunity to do something where people
will say "Hey look, that formidable Haskell compiler is doing
something that's friendlier than the equivalent in any other
compiler!".  For such an important user-facing feature I don't
understand why we're not asking users what they prefer.

Where could I be going wrong in my understanding?

Tom

From rae at richarde.dev  Wed Jun  2 19:03:25 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 2 Jun 2021 19:03:25 +0000
Subject: value of documenting error messages?
In-Reply-To: <20210602184811.GI4204@cloudinit-builder>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
 <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
 <20210602174921.GQ27384@cloudinit-builder>
 <010f0179cdedffd6-f1bb68b3-f8bd-4987-a5e2-d5312360e3f2-000000@us-east-2.amazonses.com>
 <20210602184811.GI4204@cloudinit-builder>
Message-ID: <010f0179ce1be6d0-29450210-4631-4654-9e5c-747eaf9154cb-000000@us-east-2.amazonses.com>



> On Jun 2, 2021, at 2:48 PM, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> 
> On Wed, Jun 02, 2021 at 06:13:17PM +0000, Richard Eisenberg wrote:
>> I'm in favor of short, undescriptive, quite-possibly numeric error
>> codes.
> 
> These responses are so completely opposite to what I expected that I
> can't help thinking I've made a fundamental error in my understanding
> of what we're trying to achieve!  Since no one has suggested any
> support for the idea of descriptive error codes I'm pressing on mostly
> in the hope that someone will be able to see from where my
> misunderstanding arises and set me straight.

I see no place where our understandings have diverged, just our opinions. But I may be missing something, too, of course! (For the record, I don't see your suggestion as unreasonable; I just think it's inferior to terse non-descriptive identifiers.)

> 
> Before I continue, I'd like to suggest that this is very much a
> user-facing issue and I would be strongly in favour of actually asking
> users about what they prefer (and allowing them to discuss for a
> while) rather than taking a straw poll amongst GHC developers.
> 
> To that end, would it be inappropriate of me to link this discussion
> to Haskell Reddit and/or Haskell Discourse?

Not this discussion, but I think a discussion there is a good idea. This thread started as a question about documenting constructors in the GHC source code, and it has (rightly!) moved to be about documenting error messages more generally. I (myopically) had not connected these two, and I'm glad for the direction this has taken. But I think the user-facing discussion should have a different starting point than this thread.

I don't think I currently have the bandwidth for that discussion, but if no one else starts it, I will before too much longer.

> 
> I don't understand at all why it's valuable to sequentialize.  Is the
> relative ordering of error codes meaningful in some way?

No. Sequentialization is good because it allows for the production of a new, unique member of the class, with a minimum of storage requirements (that is, you just store the greatest such member, and you know the next one up is unique).

> 
> I don't see why deprecating an error code and reintroducing it is a
> problem any more than doing the same to a function or GHC extension.

It is definitely worse than a function, because functions are associated with a particular version. If GHC 9 and GHC 13 have a function of the same name but different meanings, I don't see how that causes trouble.

Extensions and error codes, on the other hand, are more troublesome, because they get documented and discussed widely online, and web pages live forever. And it is currently sometimes problematic when extensions change meaning over time, leading to conversations I've seen about adding version numbers to extensions. I don't think we've had an extension disappear and then reappear, because removing an extension is very, very hard. Error messages, on the hand, will be much more fluid.

> 
> 
>> Easy to make compositional. We can choose to have all GHC error
>> codes begin with G (for GHC). Then Cabal could use C, Haddock could
>> use H, and Stack could use S. This makes it easy for users to tell
>> (once they've learned the scheme) where an error has come from.
> 
> Surely the same holds for descriptive error codes.  One could have
> G_conflicting_trait_implementations, H_malformatted_section_header,
> ...

Yes, I thought you might say that. But now these are mixed, with an opaque component and a more descriptive one. Better would be ghc_conflicting_trait_implementations, but that's even longer!

> 
>> Short.
> 
> Again I must be misunderstanding.  Why is brevity valuable?  Aren't we
> expecting users to read these things and look them up?  Copy/paste is
> free.

Short things are easier to format? Yes, I agree that brevity is harder to motivate here. Yet I also think that, say, pasting the entire error message text would be wrong, too. So why do we want abbreviations at all? I think: it's to be sure we're looking up what we intend to look up, something served nicely by guaranteed uniqueness.

> 
>> No chance for misspellings during transcription. When I'm copying a
>> terse identifier, I know I have to get every glyph correct. If I
>> remember that the error code is "bad_generalizing", I might not know
>> how "generalizing" is spelled. I might also forget whether it's
>> "generalizing" or "generalization". And I could very easily see
>> myself making either both of these mistakes as I'm switching from
>> one window to another, in under a second.
> 
> Surely it's just as easy to mistype E159 as E195 as it is to misspell
> "generalise".  As above, copy/paste is free and if we *really* want to
> be helpful then instead of naked error codes we should give URLs whch
> directly link to sections in the GHC users guide (or other appropriate
> resource).

I'd be very happy with URLs.

> 
>> Disadvantages:
> 
>> The code does not impart semantic meaning. But I argue this is not
>> so bad, as even a more descriptive code does not impart a precise
>> enough semantic meaning to be helpful.
> 
> I challenge you to name your next GHC extension X25!

I *am* waiting for the day when I can figure out what -XKCD does.
> 
> Possibly ... possibly not.
> 
> "Hey Anna, what should I do about E159?"
> 
> "Hey Anna, what should I do about conflicting_trait_implementations?"
> 
> Which would I prefer to shout to my colleague across the room?

It depends on the colleague. There's a chance she knows about E159, and then the first works fine. There's a chance she doesn't know that conflicting_trait_implementations is an error code, and then she goes on a long lecture about conflicting trait implementations (but not about your error); then the second one fails.

> 
> 
> To me this seems like a rare opportunity to do something where people
> will say "Hey look, that formidable Haskell compiler is doing
> something that's friendlier than the equivalent in any other
> compiler!".  For such an important user-facing feature I don't
> understand why we're not asking users what they prefer.

I agree completely here! Let's ask! (Remember that this thread, posted to ghc-devs, was originally about documenting the GHC source code, something that would not affect users.)

Richard

From simonpj at microsoft.com  Wed Jun  2 19:06:59 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 2 Jun 2021 19:06:59 +0000
Subject: ghcup failed
Message-ID: <AM5PR83MB03531BE108E0F25353319EE4AD3D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>

Dear devs
I wanted to install GHC 8.10 on my WSL2 (Windows Subsystem for Linux) computer.  So I went here
https://www.haskell.org/ghcup/
and followed the instructions (the curl … command).  There was a long pause then

[ Info  ] verifying digest of: ghc-8.10.4-x86_64-deb9-linux.tar.xz

[ Info  ] Unpacking: ghc-8.10.4-x86_64-deb9-linux.tar.xz to /tmp/ghcup-khiegA

[ Info  ] Installing GHC (this may take a while)

[ Error ] BuildFailed failed in dir "/tmp/ghcup-khiegA": NonZeroExit 2 "make" ["install"]

    Check the logs at "/home/simonpj/.ghcup/logs" and the build directory "/tmp/ghcup-khiegA" for more clues.

    Make sure to clean up "/tmp/ghcup-khiegA" afterwards.

"_eghcup --cache install ghc recommended" failed!
I looked in the logs as suggested, and found this in the tail of ghc-make.log

Installing library in /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/libiserv-8.10.4

"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy compiler stage2 "strip" '' '/home/simonpj/.ghcup/ghc/8.10.4' '/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4' '/home/simonpj/.ghcup/ghc/8.10.4/share/doc/ghc-8.10.4/html/libraries' 'v p dyn'

Installing library in /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/ghc-8.10.4

"/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/bin/ghc-pkg" --force --global-package-db "/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d" update rts/dist/package.conf.install

ghc-pkg: Couldn't open database /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d for modification: {handle: /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d/package.cache.lock}: hLock: invalid argument (Invalid argument)

ghc.mk:967: recipe for target 'install_packages' failed

make[1]: *** [install_packages] Error 1

Makefile:51: recipe for target 'install' failed

make: *** [install] Error 2
So I seem to be stuck.  Any ideas?  I feel embarrassed not to be able to install GHC 😊.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210602/860ae604/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Jun  2 19:10:04 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 2 Jun 2021 20:10:04 +0100
Subject: value of documenting error messages?
In-Reply-To: <010f0179ce1be6d0-29450210-4631-4654-9e5c-747eaf9154cb-000000@us-east-2.amazonses.com>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
 <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
 <20210602174921.GQ27384@cloudinit-builder>
 <010f0179cdedffd6-f1bb68b3-f8bd-4987-a5e2-d5312360e3f2-000000@us-east-2.amazonses.com>
 <20210602184811.GI4204@cloudinit-builder>
 <010f0179ce1be6d0-29450210-4631-4654-9e5c-747eaf9154cb-000000@us-east-2.amazonses.com>
Message-ID: <20210602191004.GU27384@cloudinit-builder>

On Wed, Jun 02, 2021 at 07:03:25PM +0000, Richard Eisenberg wrote:
> > To me this seems like a rare opportunity to do something where people
> > will say "Hey look, that formidable Haskell compiler is doing
> > something that's friendlier than the equivalent in any other
> > compiler!".  For such an important user-facing feature I don't
> > understand why we're not asking users what they prefer.
> 
> I agree completely here! Let's ask! (Remember that this thread,
> posted to ghc-devs, was originally about documenting the GHC source
> code, something that would not affect users.)

Yes indeed.  Let's one of us start a user-focused thread elsewhere
(whoever gets round to it first) and post a link here so interested
parties here can join in.

Tom

From jakob.bruenker at gmail.com  Wed Jun  2 19:12:30 2021
From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=)
Date: Wed, 2 Jun 2021 21:12:30 +0200
Subject: value of documenting error messages?
In-Reply-To: <20210602191004.GU27384@cloudinit-builder>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
 <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
 <20210602174921.GQ27384@cloudinit-builder>
 <010f0179cdedffd6-f1bb68b3-f8bd-4987-a5e2-d5312360e3f2-000000@us-east-2.amazonses.com>
 <20210602184811.GI4204@cloudinit-builder>
 <010f0179ce1be6d0-29450210-4631-4654-9e5c-747eaf9154cb-000000@us-east-2.amazonses.com>
 <20210602191004.GU27384@cloudinit-builder>
Message-ID: <CAJjQ6oOHzwONM8OczAsTG6u3c7UidTcfnPmvEuwFio0cja5taw@mail.gmail.com>

For what it's worth, there is an existing proposal about this topic, maybe
that's the right place to discuss it for a user-focused perspective.

See https://github.com/ghc-proposals/ghc-proposals/pull/325

Jakob

On Wed, Jun 2, 2021 at 9:10 PM Tom Ellis <
tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:

> On Wed, Jun 02, 2021 at 07:03:25PM +0000, Richard Eisenberg wrote:
> > > To me this seems like a rare opportunity to do something where people
> > > will say "Hey look, that formidable Haskell compiler is doing
> > > something that's friendlier than the equivalent in any other
> > > compiler!".  For such an important user-facing feature I don't
> > > understand why we're not asking users what they prefer.
> >
> > I agree completely here! Let's ask! (Remember that this thread,
> > posted to ghc-devs, was originally about documenting the GHC source
> > code, something that would not affect users.)
>
> Yes indeed.  Let's one of us start a user-focused thread elsewhere
> (whoever gets round to it first) and post a link here so interested
> parties here can join in.
>
> Tom
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210602/a0a9e444/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Jun  2 19:45:21 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 2 Jun 2021 20:45:21 +0100
Subject: ghcup failed
In-Reply-To: <AM5PR83MB03531BE108E0F25353319EE4AD3D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <AM5PR83MB03531BE108E0F25353319EE4AD3D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <20210602194521.GW27384@cloudinit-builder>

On Wed, Jun 02, 2021 at 07:06:59PM +0000, Simon Peyton Jones via ghc-devs wrote:
> Dear devs
> I wanted to install GHC 8.10 on my WSL2 (Windows Subsystem for Linux) computer.
[...]
> ghc-pkg: Couldn't open database /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d for modification: {handle: /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d/package.cache.lock}: hLock: invalid argument (Invalid argument)

Turns out it was actually WSL1 and upgrading to WSL2 resolved the
problem.

From simonpj at microsoft.com  Wed Jun  2 19:52:59 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 2 Jun 2021 19:52:59 +0000
Subject: ghcup failed
In-Reply-To: <AM5PR83MB03531BE108E0F25353319EE4AD3D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <AM5PR83MB03531BE108E0F25353319EE4AD3D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <AM5PR83MB0353271AD07D30EA2A98A485AD3D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>

Update: Tom Ellis helped me to discover that I probably had not completed my WSL1 -> WSL2 changeover on my laptop, so the error I got below came from WSL1.
Once we’d unravelled that, the error went away.  So it seems that WSL1 is to blame, not ghcup, happily.
I wonder if someone might add to this page https://www.haskell.org/ghcup/

  *   a prominent notice saying “Does not work with WLS1”,
  *   explaining how to find out how to know what version you are running (wsl -l -v in Powershell)
  *   pointing to the instructions for upgrading to WSL2 https://docs.microsoft.com/en-us/windows/wsl/install-win10
Thanks
Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Simon Peyton Jones via ghc-devs
Sent: 02 June 2021 20:07
To: GHC <ghc-devs at haskell.org>
Cc: Julian Ospald <hasufell at posteo.de>
Subject: ghcup failed

Dear devs
I wanted to install GHC 8.10 on my WSL2 (Windows Subsystem for Linux) computer.  So I went here
https://www.haskell.org/ghcup/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.haskell.org%2Fghcup%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C941d2a501a8a451f026b08d925f9c287%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637582576926132378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qbhmg5LysvmW2srYmLM2AONWdG5SvZJVOtRFFFlHfNw%3D&reserved=0>
and followed the instructions (the curl … command).  There was a long pause then

[ Info  ] verifying digest of: ghc-8.10.4-x86_64-deb9-linux.tar.xz

[ Info  ] Unpacking: ghc-8.10.4-x86_64-deb9-linux.tar.xz to /tmp/ghcup-khiegA

[ Info  ] Installing GHC (this may take a while)

[ Error ] BuildFailed failed in dir "/tmp/ghcup-khiegA": NonZeroExit 2 "make" ["install"]

    Check the logs at "/home/simonpj/.ghcup/logs" and the build directory "/tmp/ghcup-khiegA" for more clues.

    Make sure to clean up "/tmp/ghcup-khiegA" afterwards.

"_eghcup --cache install ghc recommended" failed!
I looked in the logs as suggested, and found this in the tail of ghc-make.log

Installing library in /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/libiserv-8.10.4

"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy compiler stage2 "strip" '' '/home/simonpj/.ghcup/ghc/8.10.4' '/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4' '/home/simonpj/.ghcup/ghc/8.10.4/share/doc/ghc-8.10.4/html/libraries' 'v p dyn'

Installing library in /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/ghc-8.10.4

"/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/bin/ghc-pkg" --force --global-package-db "/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d" update rts/dist/package.conf.install

ghc-pkg: Couldn't open database /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d for modification: {handle: /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d/package.cache.lock}: hLock: invalid argument (Invalid argument)

ghc.mk:967: recipe for target 'install_packages' failed

make[1]: *** [install_packages] Error 1

Makefile:51: recipe for target 'install' failed

make: *** [install] Error 2
So I seem to be stuck.  Any ideas?  I feel embarrassed not to be able to install GHC 😊.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210602/3f67896c/attachment.html>

From ietf-dane at dukhovni.org  Wed Jun  2 20:16:38 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Wed, 2 Jun 2021 16:16:38 -0400
Subject: ghcup failed
In-Reply-To: <AM5PR83MB03531BE108E0F25353319EE4AD3D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <AM5PR83MB03531BE108E0F25353319EE4AD3D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <YLfnJorZ5TAeFzQL@straasha.imrryr.org>

On Wed, Jun 02, 2021 at 07:06:59PM +0000, Simon Peyton Jones via ghc-devs wrote:

> "/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/bin/ghc-pkg" --force --global-package-db "/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d" update rts/dist/package.conf.install
> 
> ghc-pkg: Couldn't open database /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d for modification: {handle: /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d/package.cache.lock}: hLock: invalid argument (Invalid argument)

With WSL2, what sort of filesystem is /home/<username>?  Is a native
Linux filesystem (ext4, btrfs, ...) over a block device, or is it NTFS
(either shared with Windows or dedicated for WSL2)?

The "hLock" function in GHC.IO.Handle.Lock makes use of a "lockImpl"
handle that on linux typically expects to find working support for the
sane "open file descriptor locking", which avoids historical POSIX lock
breakage by using:

       F_OFD_SETLK
       F_OFD_SETLKW
       F_OFD_GETLK

The supporting is in GHC.IO.Handle.Lock.LinuxOFD.  It appears that

       F_OFD_SETLKW

is failing on WSL2 with EINVAL.  It is not clear whether the issue is
lack of support for F_OFD_SETLKW in the fcntl(2) implementation, or
something about the structure that's passed to acquire the lock:

    instance Storable FLock where
        sizeOf _ = #{size struct flock}
        alignment _ = #{alignment struct flock}
        poke ptr x = do
            fillBytes ptr 0 (sizeOf x)
            #{poke struct flock, l_type}   ptr (l_type x)
            #{poke struct flock, l_whence} ptr (l_whence x)
            #{poke struct flock, l_start}  ptr (l_start x)
            #{poke struct flock, l_len}    ptr (l_len x)
            #{poke struct flock, l_pid}    ptr (l_pid x)
        peek ptr =
            FLock <$> #{peek struct flock, l_type}   ptr
                  <*> #{peek struct flock, l_whence} ptr
                  <*> #{peek struct flock, l_start}  ptr
                  <*> #{peek struct flock, l_len}    ptr
                  <*> #{peek struct flock, l_pid}    ptr

or perhaps an issue with locking generally for the filesystem in
question.

Whether the lock is per open file or per file object across all its
open instances (POSIX breakage) should not depend on the filesystem
type, so if locking works with F_SETLKW, it should also work with
F_OFD_SETLW, provided the latter is supported at all.

It should be possible to test lock support on WSL2 with a simple
program (source attached), compiled via:

    $ make CFLAGS=-D_GNU_SOURCE ofdlock

and executed (with CWD in the relevant filesystem):

    $ ./ofdlock ofdlock.dat
    Size of struct flock = 32
      l_type ofset = 0
      l_whence ofset = 2
      l_start ofset = 8
      l_len ofset = 16
      l_pid ofset = 24

This should not report any errors, and should return a size and
structure offset values that match the upstream compilation environment.

-- 
    Viktor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ofdlock.c
Type: text/x-csrc
Size: 1105 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210602/eadd2617/attachment.c>

From karel.gardas at centrum.cz  Wed Jun  2 20:23:08 2021
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Wed, 2 Jun 2021 22:23:08 +0200
Subject: ghcup failed
In-Reply-To: <YLfnJorZ5TAeFzQL@straasha.imrryr.org>
References: <AM5PR83MB03531BE108E0F25353319EE4AD3D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <YLfnJorZ5TAeFzQL@straasha.imrryr.org>
Message-ID: <451cc71f-9188-3faf-8306-30d0eaf8dbbc@centrum.cz>

On 6/2/21 10:16 PM, Viktor Dukhovni wrote:
> On Wed, Jun 02, 2021 at 07:06:59PM +0000, Simon Peyton Jones via ghc-devs wrote:
> 
>> "/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/bin/ghc-pkg" --force --global-package-db "/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d" update rts/dist/package.conf.install
>>
>> ghc-pkg: Couldn't open database /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d for modification: {handle: /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d/package.cache.lock}: hLock: invalid argument (Invalid argument)
> 
> With WSL2, what sort of filesystem is /home/<username>?  Is a native
> Linux filesystem (ext4, btrfs, ...) over a block device, or is it NTFS
> (either shared with Windows or dedicated for WSL2)?

IIRC

WSL1 is using windows kernel and Linux support is cooked on top of that
somehow -- like linuxator in freebsd or so. Linux syscalls emulated.

WSL2 is using hyper-v and linux kernel, hence is more or less like
normal linux.

From matthewtpickering at gmail.com  Thu Jun  3 07:52:05 2021
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Thu, 3 Jun 2021 08:52:05 +0100
Subject: GHC and the future of Freenode
In-Reply-To: <e7c7461d-2bf8-7b17-e51d-13d2beca1a77@obsidian.systems>
References: <877djuanm3.fsf@smart-cactus.org>
 <CAEDGBq+qr+jxxmNhkAUpR-wt7eOxt6mWkM-3mW6gEWJFwWu0HA@mail.gmail.com>
 <CAKfdd-zFCUCEFSWtEx8L=ijSu4NrH86mS-jPH8kfuU4L5cBizQ@mail.gmail.com>
 <CAGK9nuru+hrBng-U8ajEehyEjhdxGGSGQz52ZSJeNd6C9CayRg@mail.gmail.com>
 <87lf887zn4.fsf@smart-cactus.org>
 <CAGK9nuqW8Z+YREWCaoTWJrP99qGazgQ5ZBrB_9ToLW5pXTNy3g@mail.gmail.com>
 <e7c7461d-2bf8-7b17-e51d-13d2beca1a77@obsidian.systems>
Message-ID: <CALuQ0m9Woqj5z07fUm5MxOV8BdeKRv1o4mx6qbddJV3XTzThTA@mail.gmail.com>

I have been trying out Matrix a bit recently. It seems the best of the
options in my opinion and has the advantage of being able to bridge to
IRC (and other platforms).

The NixOS community rapidly moved over without any ill effects after
the demise of freenode.

As with all these things, who feels willing to make a decision for us?

Cheers,

Matt

On Sat, May 22, 2021 at 7:52 PM John Ericson
<john.ericson at obsidian.systems> wrote:
>
> As Ben and others say, Matrix provides many modern features new users will expect, while preserving the spirit of IRC. Without wading into the details, the design of Matrix I find impressive and to my liking, and it has seemed to get steadily better over time for quite a while now.
>
> Re Zulip, in https://news.ycombinator.com/item?id=27202838 one of the lead Matrix devs says their up-and-coming threading model aims to support what Zulip does and they've been discussing deeper integration with Zulip. Granted, It would be better to hear about those discussions from the Zulip side as Matrix aims to assimilate everything and Zulip could have some reservations, but I remain hopeful. (I certainly would like to see culled the current explosion of mutually-incompatible chat applications, leaving us with fewer protocols but as many competing implementations.)
>
> What I recommend for now that we make some official Matrix channels, but also bridge them with the libera.chat ones once the bridge is up (should be a few days). Creating a matrix room and bridging it is a bit different underneath the hood than using a channel generated by the bridge on demand. We can give them nice names on the matrix side, and basically keep both options open of being "IRC-first" or "Matrix-first" down the road.
>
> For reference, see https://matrix.to/#/#community:nixos.org?via=nixos.org which is the Matrix "Space" (room that is a directory of sub-rooms, filling the role of a Discord "server") that Nix community created while they debate what to do next. See also https://github.com/NixOS/rfcs/pull/94 where this same discussion is playing out.
>
> John
>
> On 5/21/21 4:00 PM, Iavor Diatchki wrote:
>
> As I said, I am not a heavy IRC user, for my online chatting needs I mostly use Mattermost, Discord, and Slack.    So I don't have an informed opinion on the technical merits of the various platforms---mostly I've heard that the Matrix clients and servers are quite a bit less robust than IRC ones but I've never personally used them.
>
> If there is a feeling that GHC wants to use a new chatting platform, by all means we should try it out.  I just don't think that the unfortunate situation with free-node is a good reason to drop IRC entirely.   Despite its flows, I think it has served our community well, and while it may look "old" to "young" users it does have the benefit of being pretty stable, unlike the myriad of chatting services that seem to be popping up all the time.
>
> -Iavor
>
>
>
> On Fri, May 21, 2021 at 10:41 AM Ben Gamari <ben at smart-cactus.org> wrote:
>>
>> Iavor Diatchki <iavor.diatchki at gmail.com> writes:
>>
>> > Hello,
>> >
>> > I am not a heavy IRC user, but I'd say it makes most sense to just use
>> > Libera.  It is essentially the same people that were running free-node
>> > running pretty much the exact same service, and I believe they are trying
>> > to make it extra easy to just switch, so this should be the least effort
>> > transition.
>> >
>> > I believe IRC has served the GHC community quite well so far, and there is
>> > a reddit post by Ed Kmett that the normal Haskell channels have already
>> > been transitioned over, so I think it makes sense for GHC to stick with the
>> > rest of the Haskell community.
>> >
>> The problem is that, in order to grow (or even merely not to shrink),
>> the community also needs to adapt to the preferences of younger users.
>>
>> The fact of the matter is the younger users tend to be, at best,
>> unfamiliar with IRC. In the worst case, the need to leave a browser/sign
>> up for a new account means that they simply won't participate. Of the
>> new contributors I have had approach me in the past year, less than half
>> have had any familiarity with IRC.
>>
>> Matrix has the advantage of being accessible to "web-native" community
>> members while being open enough to (at least in principle) allow
>> community members who are accustomed to IRC to continue to participate
>> via a bridge.
>>
>> Cheers,
>>
>> - Ben
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From alan.zimm at gmail.com  Thu Jun  3 18:50:29 2021
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 3 Jun 2021 19:50:29 +0100
Subject: value of documenting error messages?
In-Reply-To: <CAJjQ6oOHzwONM8OczAsTG6u3c7UidTcfnPmvEuwFio0cja5taw@mail.gmail.com>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
 <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
 <20210602174921.GQ27384@cloudinit-builder>
 <010f0179cdedffd6-f1bb68b3-f8bd-4987-a5e2-d5312360e3f2-000000@us-east-2.amazonses.com>
 <20210602184811.GI4204@cloudinit-builder>
 <010f0179ce1be6d0-29450210-4631-4654-9e5c-747eaf9154cb-000000@us-east-2.amazonses.com>
 <20210602191004.GU27384@cloudinit-builder>
 <CAJjQ6oOHzwONM8OczAsTG6u3c7UidTcfnPmvEuwFio0cja5taw@mail.gmail.com>
Message-ID: <CANma=H-ggZ81c3OaPNsAqTPtLsxu2ZZT_waEZxve+bKx5JtdGg@mail.gmail.com>

I think in practical terms for IDE-based people, a short standardised
alphanumeric identifier makes sense. These typically get displayed along
with the full error text in the error pane, and it helps to be able to
allocate a known, standard amount of real estate to them.  Fundamentally
they are just an index into something else, you will either copy/paste it,
or click on it.

Alan

On Wed, 2 Jun 2021 at 20:16, Jakob Brünker <jakob.bruenker at gmail.com> wrote:

> For what it's worth, there is an existing proposal about this topic, maybe
> that's the right place to discuss it for a user-focused perspective.
>
> See https://github.com/ghc-proposals/ghc-proposals/pull/325
>
> Jakob
>
> On Wed, Jun 2, 2021 at 9:10 PM Tom Ellis <
> tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
>
>> On Wed, Jun 02, 2021 at 07:03:25PM +0000, Richard Eisenberg wrote:
>> > > To me this seems like a rare opportunity to do something where people
>> > > will say "Hey look, that formidable Haskell compiler is doing
>> > > something that's friendlier than the equivalent in any other
>> > > compiler!".  For such an important user-facing feature I don't
>> > > understand why we're not asking users what they prefer.
>> >
>> > I agree completely here! Let's ask! (Remember that this thread,
>> > posted to ghc-devs, was originally about documenting the GHC source
>> > code, something that would not affect users.)
>>
>> Yes indeed.  Let's one of us start a user-focused thread elsewhere
>> (whoever gets round to it first) and post a link here so interested
>> parties here can join in.
>>
>> Tom
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210603/9b11abeb/attachment.html>

From john.ericson at obsidian.systems  Thu Jun  3 19:27:36 2021
From: john.ericson at obsidian.systems (John Ericson)
Date: Thu, 3 Jun 2021 15:27:36 -0400
Subject: GHC and the future of Freenode
In-Reply-To: <CALuQ0m9Woqj5z07fUm5MxOV8BdeKRv1o4mx6qbddJV3XTzThTA@mail.gmail.com>
References: <877djuanm3.fsf@smart-cactus.org>
 <CAEDGBq+qr+jxxmNhkAUpR-wt7eOxt6mWkM-3mW6gEWJFwWu0HA@mail.gmail.com>
 <CAKfdd-zFCUCEFSWtEx8L=ijSu4NrH86mS-jPH8kfuU4L5cBizQ@mail.gmail.com>
 <CAGK9nuru+hrBng-U8ajEehyEjhdxGGSGQz52ZSJeNd6C9CayRg@mail.gmail.com>
 <87lf887zn4.fsf@smart-cactus.org>
 <CAGK9nuqW8Z+YREWCaoTWJrP99qGazgQ5ZBrB_9ToLW5pXTNy3g@mail.gmail.com>
 <e7c7461d-2bf8-7b17-e51d-13d2beca1a77@obsidian.systems>
 <CALuQ0m9Woqj5z07fUm5MxOV8BdeKRv1o4mx6qbddJV3XTzThTA@mail.gmail.com>
Message-ID: <e0341771-d58f-4cea-f345-c27629a07a0c@obsidian.systems>

The libera.chat IRC bridge is up, so one can go to #ghc:libera.chat to 
give the bridging a spin.

To make my recommendation from before more concrete, we would *not* use 
that "portal room" (one spawned on demand by the bridge), but instead 
make a #ghc:haskell.org. One should be able to then "tombstone" the 
portal room telling people to go to the manually-bridged instead, which 
can preserve history across bridging changes like e.g. libera.chat and 
Freenode are reunited later, adding slack/discord bridges, etc.

John

On 6/3/21 3:52 AM, Matthew Pickering wrote:
> I have been trying out Matrix a bit recently. It seems the best of the
> options in my opinion and has the advantage of being able to bridge to
> IRC (and other platforms).
>
> The NixOS community rapidly moved over without any ill effects after
> the demise of freenode.
>
> As with all these things, who feels willing to make a decision for us?
>
> Cheers,
>
> Matt
>
> On Sat, May 22, 2021 at 7:52 PM John Ericson
> <john.ericson at obsidian.systems> wrote:
>> As Ben and others say, Matrix provides many modern features new users will expect, while preserving the spirit of IRC. Without wading into the details, the design of Matrix I find impressive and to my liking, and it has seemed to get steadily better over time for quite a while now.
>>
>> Re Zulip, in https://news.ycombinator.com/item?id=27202838 one of the lead Matrix devs says their up-and-coming threading model aims to support what Zulip does and they've been discussing deeper integration with Zulip. Granted, It would be better to hear about those discussions from the Zulip side as Matrix aims to assimilate everything and Zulip could have some reservations, but I remain hopeful. (I certainly would like to see culled the current explosion of mutually-incompatible chat applications, leaving us with fewer protocols but as many competing implementations.)
>>
>> What I recommend for now that we make some official Matrix channels, but also bridge them with the libera.chat ones once the bridge is up (should be a few days). Creating a matrix room and bridging it is a bit different underneath the hood than using a channel generated by the bridge on demand. We can give them nice names on the matrix side, and basically keep both options open of being "IRC-first" or "Matrix-first" down the road.
>>
>> For reference, see https://matrix.to/#/#community:nixos.org?via=nixos.org which is the Matrix "Space" (room that is a directory of sub-rooms, filling the role of a Discord "server") that Nix community created while they debate what to do next. See also https://github.com/NixOS/rfcs/pull/94 where this same discussion is playing out.
>>
>> John
>>
>> On 5/21/21 4:00 PM, Iavor Diatchki wrote:
>>
>> As I said, I am not a heavy IRC user, for my online chatting needs I mostly use Mattermost, Discord, and Slack.    So I don't have an informed opinion on the technical merits of the various platforms---mostly I've heard that the Matrix clients and servers are quite a bit less robust than IRC ones but I've never personally used them.
>>
>> If there is a feeling that GHC wants to use a new chatting platform, by all means we should try it out.  I just don't think that the unfortunate situation with free-node is a good reason to drop IRC entirely.   Despite its flows, I think it has served our community well, and while it may look "old" to "young" users it does have the benefit of being pretty stable, unlike the myriad of chatting services that seem to be popping up all the time.
>>
>> -Iavor
>>
>>
>>
>> On Fri, May 21, 2021 at 10:41 AM Ben Gamari <ben at smart-cactus.org> wrote:
>>> Iavor Diatchki <iavor.diatchki at gmail.com> writes:
>>>
>>>> Hello,
>>>>
>>>> I am not a heavy IRC user, but I'd say it makes most sense to just use
>>>> Libera.  It is essentially the same people that were running free-node
>>>> running pretty much the exact same service, and I believe they are trying
>>>> to make it extra easy to just switch, so this should be the least effort
>>>> transition.
>>>>
>>>> I believe IRC has served the GHC community quite well so far, and there is
>>>> a reddit post by Ed Kmett that the normal Haskell channels have already
>>>> been transitioned over, so I think it makes sense for GHC to stick with the
>>>> rest of the Haskell community.
>>>>
>>> The problem is that, in order to grow (or even merely not to shrink),
>>> the community also needs to adapt to the preferences of younger users.
>>>
>>> The fact of the matter is the younger users tend to be, at best,
>>> unfamiliar with IRC. In the worst case, the need to leave a browser/sign
>>> up for a new account means that they simply won't participate. Of the
>>> new contributors I have had approach me in the past year, less than half
>>> have had any familiarity with IRC.
>>>
>>> Matrix has the advantage of being accessible to "web-native" community
>>> members while being open enough to (at least in principle) allow
>>> community members who are accustomed to IRC to continue to participate
>>> via a bridge.
>>>
>>> Cheers,
>>>
>>> - Ben
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From b at chreekat.net  Thu Jun  3 19:41:35 2021
From: b at chreekat.net (Bryan Richter)
Date: Thu, 3 Jun 2021 22:41:35 +0300
Subject: value of documenting error messages?
In-Reply-To: <CAJjQ6oOHzwONM8OczAsTG6u3c7UidTcfnPmvEuwFio0cja5taw@mail.gmail.com>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
 <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
 <20210602174921.GQ27384@cloudinit-builder>
 <010f0179cdedffd6-f1bb68b3-f8bd-4987-a5e2-d5312360e3f2-000000@us-east-2.amazonses.com>
 <20210602184811.GI4204@cloudinit-builder>
 <010f0179ce1be6d0-29450210-4631-4654-9e5c-747eaf9154cb-000000@us-east-2.amazonses.com>
 <20210602191004.GU27384@cloudinit-builder>
 <CAJjQ6oOHzwONM8OczAsTG6u3c7UidTcfnPmvEuwFio0cja5taw@mail.gmail.com>
Message-ID: <CAH9BU=yBk8wH=t_h1KwDu40Xc_NGFpggtYssN_63ZjDJTbTw8A@mail.gmail.com>

By the way, to summarize the discussion on #325, I think the words to use
would be "overwhelming support for short numeric reference ids".

Here's my argument for it:

1. If you try to make the unique id some mangled form of the error's name,
the cognitive burden of crafting errors is increased. Professional
experience leads me to believe this is no laughing matter.

2. A unique id will never replace pithy error messages, clear error names,
nor detailed reference documentation anyway.

3. Numeric ids are internationalized (well, at least multi-nationalized) by
construction.

4. Numeric ids, having no intrinsic meaning, are perfectly
forward-compatible with any potential evolution of error names or
descriptions.


-Bryan


On Wed, Jun 2, 2021 at 10:15 PM Jakob Brünker <jakob.bruenker at gmail.com>
wrote:

> For what it's worth, there is an existing proposal about this topic, maybe
> that's the right place to discuss it for a user-focused perspective.
>
> See https://github.com/ghc-proposals/ghc-proposals/pull/325
>
> Jakob
>
> On Wed, Jun 2, 2021 at 9:10 PM Tom Ellis <
> tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
>
>> On Wed, Jun 02, 2021 at 07:03:25PM +0000, Richard Eisenberg wrote:
>> > > To me this seems like a rare opportunity to do something where people
>> > > will say "Hey look, that formidable Haskell compiler is doing
>> > > something that's friendlier than the equivalent in any other
>> > > compiler!".  For such an important user-facing feature I don't
>> > > understand why we're not asking users what they prefer.
>> >
>> > I agree completely here! Let's ask! (Remember that this thread,
>> > posted to ghc-devs, was originally about documenting the GHC source
>> > code, something that would not affect users.)
>>
>> Yes indeed.  Let's one of us start a user-focused thread elsewhere
>> (whoever gets round to it first) and post a link here so interested
>> parties here can join in.
>>
>> Tom
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210603/5838edc2/attachment.html>

From carter.schonwald at gmail.com  Thu Jun  3 19:59:32 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 3 Jun 2021 15:59:32 -0400
Subject: value of documenting error messages?
In-Reply-To: <CANma=H-ggZ81c3OaPNsAqTPtLsxu2ZZT_waEZxve+bKx5JtdGg@mail.gmail.com>
References: <010f0179c98044de-eacf7a76-1acd-470d-a46e-336a56a327c7-000000@us-east-2.amazonses.com>
 <CAFYDutEecqc0tzg-F5tav6cYNr+d3MnOkv1v=aL+1LN81vWf=w@mail.gmail.com>
 <20210602104614.GP27384@cloudinit-builder>
 <fb4819eb-b1e4-f60c-e734-699157729aa5@gmail.com>
 <20210602174921.GQ27384@cloudinit-builder>
 <010f0179cdedffd6-f1bb68b3-f8bd-4987-a5e2-d5312360e3f2-000000@us-east-2.amazonses.com>
 <20210602184811.GI4204@cloudinit-builder>
 <010f0179ce1be6d0-29450210-4631-4654-9e5c-747eaf9154cb-000000@us-east-2.amazonses.com>
 <20210602191004.GU27384@cloudinit-builder>
 <CAJjQ6oOHzwONM8OczAsTG6u3c7UidTcfnPmvEuwFio0cja5taw@mail.gmail.com>
 <CANma=H-ggZ81c3OaPNsAqTPtLsxu2ZZT_waEZxve+bKx5JtdGg@mail.gmail.com>
Message-ID: <CAHYVw0zu4E9d9XB_oGUweRxJDTnNYMr=R+BepGsr+WJeh28d1w@mail.gmail.com>

Yes! Thanks for articulating it so nicely

On Thu, Jun 3, 2021 at 2:51 PM Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> I think in practical terms for IDE-based people, a short standardised
> alphanumeric identifier makes sense. These typically get displayed along
> with the full error text in the error pane, and it helps to be able to
> allocate a known, standard amount of real estate to them.  Fundamentally
> they are just an index into something else, you will either copy/paste it,
> or click on it.
>
> Alan
>
> On Wed, 2 Jun 2021 at 20:16, Jakob Brünker <jakob.bruenker at gmail.com>
> wrote:
>
>> For what it's worth, there is an existing proposal about this topic,
>> maybe that's the right place to discuss it for a user-focused perspective.
>>
>> See https://github.com/ghc-proposals/ghc-proposals/pull/325
>>
>> Jakob
>>
>> On Wed, Jun 2, 2021 at 9:10 PM Tom Ellis <
>> tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
>>
>>> On Wed, Jun 02, 2021 at 07:03:25PM +0000, Richard Eisenberg wrote:
>>> > > To me this seems like a rare opportunity to do something where people
>>> > > will say "Hey look, that formidable Haskell compiler is doing
>>> > > something that's friendlier than the equivalent in any other
>>> > > compiler!".  For such an important user-facing feature I don't
>>> > > understand why we're not asking users what they prefer.
>>> >
>>> > I agree completely here! Let's ask! (Remember that this thread,
>>> > posted to ghc-devs, was originally about documenting the GHC source
>>> > code, something that would not affect users.)
>>>
>>> Yes indeed.  Let's one of us start a user-focused thread elsewhere
>>> (whoever gets round to it first) and post a link here so interested
>>> parties here can join in.
>>>
>>> Tom
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210603/eca5b884/attachment.html>

From moritz.angermann at gmail.com  Sat Jun  5 08:00:38 2021
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 5 Jun 2021 16:00:38 +0800
Subject: [CI] macOS builds
Message-ID: <CAKfdd-yTrpbnS5gmWnWpaidF=3apb9eCVkJ2fsYLF4Bgg0A7wQ@mail.gmail.com>

Hi there!

You might have seen failed or stuck or pending darwin builds. Our CI
builders we got generously donated have ~250GB of disk space (which should
be absolutely adequat for what we do), and macOS BigSur does some odd
reservation of 200GB in /System/Volumes/Data, this is despite automatic
updates being disabled and time machine being disabled.

It used to happen only when the system was expecting an update to be
performed and the 200GB were freed after the update was done. After the
latest update to 11.4, however, it seems to have not freed that space. This
leaves the CI machine with ~50GB for for the system + build tools + gitlab
checkouts and builds, and they frequently run out of space :-/

If someone knows how to prevent the system from doing stupid stuff like
this (my hunch is it's keeping a backup of the system pre-udpate, for
disaster recovery). Please come forward, my google searches haven't
revealed anything useful yet.

I have filed a TSI with Apple (still had a few on my developer account),
but I don't expect them to come back to me before the end of June. Next
week is WWDC, and there will be a massive backlog of issues that queued up
leading up to, and during the WWDC.  I've also only had very marginal
success with them resolving issues that were not "you wrote this program
wrong".

If everything fails, maybe the solution is to attach some usbc ssd's to the
macs and have gitlab builds be run dedicatedly on those disks. I'm a bit
concerned about performance but we would have to see.

Any ideas are welcome, please also feel free to hit me up on
libera.chat#ghc, or the haskell foundations slack.

Cheers,
 Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210605/b3988f70/attachment.html>

From zubin at well-typed.com  Sun Jun  6 00:10:57 2021
From: zubin at well-typed.com (Zubin Duggal)
Date: Sun, 6 Jun 2021 05:40:57 +0530
Subject: [Haskell] [ANNOUNCE] GHC 8.10.5 released
Message-ID: <20210606001057.2ku6z5zjjv5skw7q@zubin-msi>

The GHC team is very pleased to announce the availability of GHC
8.10.5. Source and binary distributions are available at the [usual
place](https://downloads.haskell.org/ghc/8.10.5/).

This release adds native ARM/Darwin support, as well as bringing
performance improvements and fixing numerous bugs of varying severity
present in the 8.10 series:

- First-class support for Apple M1 hardware using GHC's LLVM ARM backend

- Fix a bug resulting in segmentation faults where code may be unloaded
prematurely when using the parallel garbage collector (#19417) along
with other bugs in the GC and linker (#19147, #19287)

- Improve code layout fixing certain performance regressions (#18053)
and other code generation bug fixes (#19645)

- Bug fixes for signal handling when using the pthread itimer
implementation.

- Improvements to the specializer and simplifier reducing code size and
and memory usage (#17151, #18923,#18140, #10421, #18282, #13253).

- Fix a bug where typechecker plugins could be run with an inconsistent
typechecker environment (#19191).

- Fix a simplifier bug which lead to an exponential blow up and
excessive memory usage in certain cases

A complete list of bug fixes and improvements
can be found in the release notes: [release
notes](https://downloads.haskell.org/~ghc/8.10.5/docs/html/users_guide/8.10.5-notes.html)

As always, feel free to report any issues you encounter via
[gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

From zubin at well-typed.com  Sun Jun  6 00:44:30 2021
From: zubin at well-typed.com (Zubin Duggal)
Date: Sun, 6 Jun 2021 06:14:30 +0530
Subject: [Haskell] [ANNOUNCE] GHC 8.10.5 released
In-Reply-To: <20210606001057.2ku6z5zjjv5skw7q@zubin-msi>
References: <20210606001057.2ku6z5zjjv5skw7q@zubin-msi>
Message-ID: <20210606004430.gc2a6t7eglidmri6@zubin-msi>

The correct link to the release notes is:

https://downloads.haskell.org/ghc/8.10.5/docs/html/users_guide/8.10.5-notes.html

(Note the missing tilde)

Apolgies,
Zubin

From ietf-dane at dukhovni.org  Sun Jun  6 18:06:40 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 6 Jun 2021 14:06:40 -0400
Subject: GHC and the future of Freenode
In-Reply-To: <CAHYVw0wFZQj4jre_BbcrOedvqMJUE5RFrwxBjSUaCSENfEXEMQ@mail.gmail.com>
References: <877djuanm3.fsf@smart-cactus.org>
 <CAHYVw0wFZQj4jre_BbcrOedvqMJUE5RFrwxBjSUaCSENfEXEMQ@mail.gmail.com>
Message-ID: <6EEF0036-1BB3-4BF1-99A3-D5859AC4FACF@dukhovni.org>

On 19 May 2021, at 11:48 am, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> I personally vote for irc.  Perhaps via Libera. 

Perhaps I'm too much of an IRC noob, but I still found it it rather
surprising to be banned from libera.chat (my IP is blacklisted) for
pasting a 25-line build script for building GHC via hadrian on FreeBSD
into the #ghc channel.

This was in response to a discussion about issues with the bindist,
how the port is built, ... and while perhaps I'm expected to use a
paste bin, the abrupt ban was rather a harsh response.

The ban appears to have been "temporary", an hour or so later I am
able to reconnect, but this does not leave a good impression.

-- 
	Viktor.

From allbery.b at gmail.com  Sun Jun  6 18:10:36 2021
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 6 Jun 2021 14:10:36 -0400
Subject: GHC and the future of Freenode
In-Reply-To: <6EEF0036-1BB3-4BF1-99A3-D5859AC4FACF@dukhovni.org>
References: <877djuanm3.fsf@smart-cactus.org>
 <CAHYVw0wFZQj4jre_BbcrOedvqMJUE5RFrwxBjSUaCSENfEXEMQ@mail.gmail.com>
 <6EEF0036-1BB3-4BF1-99A3-D5859AC4FACF@dukhovni.org>
Message-ID: <CAKFCL4WANkbpq0P7_4R4F6Y1_-cqU76cEQ4sQMO65-LeC3HMCw@mail.gmail.com>

Pasting directly into the channel is generally a no-no on IRC. Things like
Matrix or IRCCloud convert to pastebins automatically.

On Sun, Jun 6, 2021 at 2:07 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On 19 May 2021, at 11:48 am, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> > I personally vote for irc.  Perhaps via Libera.
>
> Perhaps I'm too much of an IRC noob, but I still found it it rather
> surprising to be banned from libera.chat (my IP is blacklisted) for
> pasting a 25-line build script for building GHC via hadrian on FreeBSD
> into the #ghc channel.
>
> This was in response to a discussion about issues with the bindist,
> how the port is built, ... and while perhaps I'm expected to use a
> paste bin, the abrupt ban was rather a harsh response.
>
> The ban appears to have been "temporary", an hour or so later I am
> able to reconnect, but this does not leave a good impression.
>
> --
>         Viktor.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


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

From cdsmith at gmail.com  Sun Jun  6 22:30:18 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Sun, 6 Jun 2021 18:30:18 -0400
Subject: GHC and the future of Freenode
In-Reply-To: <6EEF0036-1BB3-4BF1-99A3-D5859AC4FACF@dukhovni.org>
References: <877djuanm3.fsf@smart-cactus.org>
 <CAHYVw0wFZQj4jre_BbcrOedvqMJUE5RFrwxBjSUaCSENfEXEMQ@mail.gmail.com>
 <6EEF0036-1BB3-4BF1-99A3-D5859AC4FACF@dukhovni.org>
Message-ID: <CAPq5Pv+UCQuoEjM7oD=7YB7SR-1SL=hc9Lh0YLVNgr0Bj41utQ@mail.gmail.com>

Viktor,

Sorry you had a bad experience.  Perhaps it will help to know that these
bans are automatically done by bots to prevent the channel from being
flooded by nefarious users.  That you were caught by it was just a
false positive because you triggered the flooding detection.  It doesn't
mean anyone was upset at you or didn't want to talk to you.  When I've seen
it happen in #haskell in the past, the person involved has been able to
immediately rejoin and resume the conversation.

Chris

On Sun, Jun 6, 2021 at 2:08 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On 19 May 2021, at 11:48 am, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> > I personally vote for irc.  Perhaps via Libera.
>
> Perhaps I'm too much of an IRC noob, but I still found it it rather
> surprising to be banned from libera.chat (my IP is blacklisted) for
> pasting a 25-line build script for building GHC via hadrian on FreeBSD
> into the #ghc channel.
>
> This was in response to a discussion about issues with the bindist,
> how the port is built, ... and while perhaps I'm expected to use a
> paste bin, the abrupt ban was rather a harsh response.
>
> The ban appears to have been "temporary", an hour or so later I am
> able to reconnect, but this does not leave a good impression.
>
> --
>         Viktor.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210606/8081df71/attachment.html>

From csaba.hruska at gmail.com  Mon Jun  7 14:17:59 2021
From: csaba.hruska at gmail.com (Csaba Hruska)
Date: Mon, 7 Jun 2021 16:17:59 +0200
Subject: abstract interpreter for GHC Core or STG
Message-ID: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>

Hello,

I wonder if there was an attempt in the past to create an abstract
interpreter for GHC Core or STG to approximate the program runtime
behaviour?
I'm curious because I'd like to turn my external STG interterpreter to an
abstract interpreter using the AAM (Abstracting Abstract Machines) method.
This approach seems promising to me because a single Haskell code base (ext
STG interpreter) could be the specification of the Haskell operational
semantics and also be a detailed static analyzer that could help
optimization transformations.
I'm interested in any attempt that happened during GHC/Haskell evolution.

Regards,
Csaba Hruska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210607/e9ddc1a8/attachment.html>

From john.ericson at obsidian.systems  Mon Jun  7 15:02:51 2021
From: john.ericson at obsidian.systems (John Ericson)
Date: Mon, 7 Jun 2021 11:02:51 -0400
Subject: GHC and the future of Freenode
In-Reply-To: <CAKFCL4WANkbpq0P7_4R4F6Y1_-cqU76cEQ4sQMO65-LeC3HMCw@mail.gmail.com>
References: <877djuanm3.fsf@smart-cactus.org>
 <CAHYVw0wFZQj4jre_BbcrOedvqMJUE5RFrwxBjSUaCSENfEXEMQ@mail.gmail.com>
 <6EEF0036-1BB3-4BF1-99A3-D5859AC4FACF@dukhovni.org>
 <CAKFCL4WANkbpq0P7_4R4F6Y1_-cqU76cEQ4sQMO65-LeC3HMCw@mail.gmail.com>
Message-ID: <4dda71eb-3a8e-51f0-e080-91ad91b92b32@obsidian.systems>

And this is a good example of how both using libera.chat and having an 
official matrix bridge with a nice name can help more people use IRC too!

On 6/6/21 2:10 PM, Brandon Allbery wrote:
> Pasting directly into the channel is generally a no-no on IRC. Things 
> like Matrix or IRCCloud convert to pastebins automatically.
>
> On Sun, Jun 6, 2021 at 2:07 PM Viktor Dukhovni <ietf-dane at dukhovni.org 
> <mailto:ietf-dane at dukhovni.org>> wrote:
>
>     On 19 May 2021, at 11:48 am, Carter Schonwald
>     <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>>
>     wrote:
>
>     > I personally vote for irc.  Perhaps via Libera.
>
>     Perhaps I'm too much of an IRC noob, but I still found it it rather
>     surprising to be banned from libera.chat (my IP is blacklisted) for
>     pasting a 25-line build script for building GHC via hadrian on FreeBSD
>     into the #ghc channel.
>
>     This was in response to a discussion about issues with the bindist,
>     how the port is built, ... and while perhaps I'm expected to use a
>     paste bin, the abrupt ban was rather a harsh response.
>
>     The ban appears to have been "temporary", an hour or so later I am
>     able to reconnect, but this does not leave a good impression.
>
>     -- 
>             Viktor.
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>
>
>
> -- 
> brandon s allbery kf8nh
> allbery.b at gmail.com <mailto:allbery.b at gmail.com>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210607/4d40aae3/attachment.html>

From carter.schonwald at gmail.com  Mon Jun  7 15:54:52 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 7 Jun 2021 11:54:52 -0400
Subject: abstract interpreter for GHC Core or STG
In-Reply-To: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>
References: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>
Message-ID: <CAHYVw0xzDQY1wuEMV6-4DzsD0d8rVk3j0wUEPUEufkPzjo9EHQ@mail.gmail.com>

I’m not aware of any currently.

I would be curious about the now relatively old work that Max bolingbroke
did for his PhD (I think it was sortah a ghc to Lua JIT?!?)

An important question is : what questions do you want the abstract
interpreter to suport?

On Mon, Jun 7, 2021 at 10:19 AM Csaba Hruska <csaba.hruska at gmail.com> wrote:

> Hello,
>
> I wonder if there was an attempt in the past to create an abstract
> interpreter for GHC Core or STG to approximate the program runtime
> behaviour?
> I'm curious because I'd like to turn my external STG interterpreter to an
> abstract interpreter using the AAM (Abstracting Abstract Machines) method.
> This approach seems promising to me because a single Haskell code base
> (ext STG interpreter) could be the specification of the Haskell operational
> semantics and also be a detailed static analyzer that could help
> optimization transformations.
> I'm interested in any attempt that happened during GHC/Haskell evolution.
>
> Regards,
> Csaba Hruska
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210607/1c3f6f5f/attachment.html>

From carter.schonwald at gmail.com  Mon Jun  7 15:58:11 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 7 Jun 2021 11:58:11 -0400
Subject: abstract interpreter for GHC Core or STG
In-Reply-To: <CAHYVw0xzDQY1wuEMV6-4DzsD0d8rVk3j0wUEPUEufkPzjo9EHQ@mail.gmail.com>
References: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>
 <CAHYVw0xzDQY1wuEMV6-4DzsD0d8rVk3j0wUEPUEufkPzjo9EHQ@mail.gmail.com>
Message-ID: <CAHYVw0zyTBfUA8Coi3EfN-sG_oNfcVi6yE42E-KQeKhxe9hJvA@mail.gmail.com>

Correction it was Thomas schilling !!
And you can Google his Phd thesis trace based just in time compilation for
lazy functional programming languages

And the associated code is on his GitHub nominolo/ lambdachine though I
think it was last touched 7 years ago

On Mon, Jun 7, 2021 at 11:54 AM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> I’m not aware of any currently.
>
> I would be curious about the now relatively old work that Max bolingbroke
> did for his PhD (I think it was sortah a ghc to Lua JIT?!?)
>
> An important question is : what questions do you want the abstract
> interpreter to suport?
>
> On Mon, Jun 7, 2021 at 10:19 AM Csaba Hruska <csaba.hruska at gmail.com>
> wrote:
>
>> Hello,
>>
>> I wonder if there was an attempt in the past to create an abstract
>> interpreter for GHC Core or STG to approximate the program runtime
>> behaviour?
>> I'm curious because I'd like to turn my external STG interterpreter to an
>> abstract interpreter using the AAM (Abstracting Abstract Machines) method.
>> This approach seems promising to me because a single Haskell code base
>> (ext STG interpreter) could be the specification of the Haskell operational
>> semantics and also be a detailed static analyzer that could help
>> optimization transformations.
>> I'm interested in any attempt that happened during GHC/Haskell evolution.
>>
>> Regards,
>> Csaba Hruska
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210607/d882d85b/attachment.html>

From csaba.hruska at gmail.com  Mon Jun  7 17:12:04 2021
From: csaba.hruska at gmail.com (Csaba Hruska)
Date: Mon, 7 Jun 2021 19:12:04 +0200
Subject: abstract interpreter for GHC Core or STG
In-Reply-To: <CAHYVw0zyTBfUA8Coi3EfN-sG_oNfcVi6yE42E-KQeKhxe9hJvA@mail.gmail.com>
References: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>
 <CAHYVw0xzDQY1wuEMV6-4DzsD0d8rVk3j0wUEPUEufkPzjo9EHQ@mail.gmail.com>
 <CAHYVw0zyTBfUA8Coi3EfN-sG_oNfcVi6yE42E-KQeKhxe9hJvA@mail.gmail.com>
Message-ID: <CANjChEqfTWC-XsZ1Hy0VMnzx7GwV7PAqJBAXWHdY=NgKOM_DEw@mail.gmail.com>

Yes, I've read Thomas Schilling's PhD thesis (Trace-based
Just-in-timeCompilation for Lazy Functional Programming Languages) a couple
of times.

My STG interpreter almost supports all kinds of primops that GHC does, and
I plan to add the missing ones in the future.
I'd like to use literally the same source code for the concrete and the
abstract interpretation. So IMO this would mean that all kinds of runtime
properties would be approximated by the abstract interpreter.
But the most important property would be the control flow information.

On Mon, Jun 7, 2021 at 5:58 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Correction it was Thomas schilling !!
> And you can Google his Phd thesis trace based just in time compilation for
> lazy functional programming languages
>
> And the associated code is on his GitHub nominolo/ lambdachine though I
> think it was last touched 7 years ago
>
> On Mon, Jun 7, 2021 at 11:54 AM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> I’m not aware of any currently.
>>
>> I would be curious about the now relatively old work that Max bolingbroke
>> did for his PhD (I think it was sortah a ghc to Lua JIT?!?)
>>
>> An important question is : what questions do you want the abstract
>> interpreter to suport?
>>
>> On Mon, Jun 7, 2021 at 10:19 AM Csaba Hruska <csaba.hruska at gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I wonder if there was an attempt in the past to create an abstract
>>> interpreter for GHC Core or STG to approximate the program runtime
>>> behaviour?
>>> I'm curious because I'd like to turn my external STG interterpreter to
>>> an abstract interpreter using the AAM (Abstracting Abstract Machines)
>>> method.
>>> This approach seems promising to me because a single Haskell code base
>>> (ext STG interpreter) could be the specification of the Haskell operational
>>> semantics and also be a detailed static analyzer that could help
>>> optimization transformations.
>>> I'm interested in any attempt that happened during GHC/Haskell evolution.
>>>
>>> Regards,
>>> Csaba Hruska
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210607/0be0f3a4/attachment.html>

From simonpj at microsoft.com  Tue Jun  8 09:08:20 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Jun 2021 09:08:20 +0000
Subject: abstract interpreter for GHC Core or STG
In-Reply-To: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>
References: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>
Message-ID: <AM5PR83MB0353865361845110ADC9E73EAD379@AM5PR83MB0353.EURPRD83.prod.outlook.com>

I wonder if there was an attempt in the past to create an abstract interpreter for GHC Core or STG to approximate the program runtime behaviour?

No, not that I know of.   Because of all the primops, concurrency, STM, etc, it would be something of a challenge.  The AAM story could be interesting…

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Csaba Hruska
Sent: 07 June 2021 15:18
To: GHC developers <ghc-devs at haskell.org>
Subject: abstract interpreter for GHC Core or STG

Hello,

I wonder if there was an attempt in the past to create an abstract interpreter for GHC Core or STG to approximate the program runtime behaviour?
I'm curious because I'd like to turn my external STG interterpreter to an abstract interpreter using the AAM (Abstracting Abstract Machines) method.
This approach seems promising to me because a single Haskell code base (ext STG interpreter) could be the specification of the Haskell operational semantics and also be a detailed static analyzer that could help optimization transformations.
I'm interested in any attempt that happened during GHC/Haskell evolution.

Regards,
Csaba Hruska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210608/52ef31e9/attachment.html>

From sam.derbyshire at gmail.com  Tue Jun  8 10:27:09 2021
From: sam.derbyshire at gmail.com (Sam Derbyshire)
Date: Tue, 8 Jun 2021 12:27:09 +0200
Subject: Rewriting plugins: request for feedback
Message-ID: <CAA1CnJPTysDy6mmD_hwCurvCP0k_+ORmxPeE0sR+1NWtbGKGkQ@mail.gmail.com>

Hi everyone,

Recent refactors to the constraint solver have complicated the story for
authors of type-checking plugins. Following a suggestion by Christiaan
Baaij, and aided by Richard Eisenberg, I'm working on adding the ability
for type-checking plugins to rewrite type family applications directly
(hooking straight into GHC's type-family rewriting code). The goal is to
ease migration for the plugin authors, hopefully simplifying the common
operation of rewriting type family applications.


Let me now describe the current API for this new functionality, for which I
would like feedback.

--------------------------------------------------------------------------

A new field is added to the TcPlugin data type, namely

tcPluginRewrite :: s -> UniqFM TyCon TcPluginRewriter

Here s is the existential plugin state that users can choose as they wish
for their own plugin.
Plugins thus register which type family TyCons they are interested in
rewriting, like so:

myTcPluginRewrite :: MyPluginState -> UniqFM TyCon TcPluginRewriter
myTcPluginRewrite s@(MyPluginState {myFam1TyCon, myFam2TyCon}) =
  listToUFM [ (myFam1TyCon, myFam1Rewriter s), (myFam2TyCon, myFam2Rewriter
s) ]

For each type family TyCon, the plugin should provide a rewriting function
(corresponding to myFam1Rewriter and myFam2Rewriter above), of type

type TcPluginRewriter = [Ct] -> [TcType] -> TcPluginM TcPluginRewriteResult

This means that a rewriting function is supplied with the current Given
constraints and the arguments of the (guaranteed to be saturated)
type-family application, and should return a result of type:

data TcPluginRewriteResult where
  TcPluginRewriteError
    :: (Diagnostic a, Typeable a) => a -> TcPluginRewriteResult
  TcPluginNoRewrite
    :: TcPluginRewriteResult
  TcPluginRewriteTo
    :: { rewriteTo :: TcType
       , rewriteEvidence :: TcCoercion }
    -> TcPluginRewriteResult

That is, the plugin can specify what the type-family application should be
rewritten to, throw an error, or do nothing.

--------------------------------------------------------------------------

I'm hoping that the components of existing type-checking plugins concerned
with type-family applications can instead use this mechanism and achieve
more robust results by doing so, with less effort.

I would like to hear from plugin authors whether this API suits their
needs. If you know of someone not on this list that might be interested,
please invite them to join the conversation.

The current state of this patch can be found in the GHC MR 5909:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5909

Thanks,

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210608/b823ec8a/attachment.html>

From carter.schonwald at gmail.com  Tue Jun  8 20:51:32 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 8 Jun 2021 16:51:32 -0400
Subject: abstract interpreter for GHC Core or STG
In-Reply-To: <AM5PR83MB0353865361845110ADC9E73EAD379@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>
 <AM5PR83MB0353865361845110ADC9E73EAD379@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <CAHYVw0yybcxbbbM24Y3UumsDBCeP4weNG1GhJNphRmsRw+s9tQ@mail.gmail.com>

The stm impl In ghcjs might be a helpful comparative example on that front.

Though I guess more broadly does this necessitate having a model of the Cmm
semantics for the out of line primops ?

On Tue, Jun 8, 2021 at 5:10 AM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> I wonder if there was an attempt in the past to create an abstract
> interpreter for GHC Core or STG to approximate the program runtime
> behaviour?
>
>
>
> No, not that I know of.   Because of all the primops, concurrency, STM,
> etc, it would be something of a challenge.  The AAM story could be
> interesting…
>
>
>
> Simon
>
>
>
> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Csaba
> Hruska
> *Sent:* 07 June 2021 15:18
> *To:* GHC developers <ghc-devs at haskell.org>
> *Subject:* abstract interpreter for GHC Core or STG
>
>
>
> Hello,
>
>
>
> I wonder if there was an attempt in the past to create an abstract
> interpreter for GHC Core or STG to approximate the program runtime
> behaviour?
>
> I'm curious because I'd like to turn my external STG interterpreter to an
> abstract interpreter using the AAM (Abstracting Abstract Machines) method.
>
> This approach seems promising to me because a single Haskell code base
> (ext STG interpreter) could be the specification of the Haskell operational
> semantics and also be a detailed static analyzer that could help
> optimization transformations.
>
> I'm interested in any attempt that happened during GHC/Haskell evolution.
>
>
>
> Regards,
>
> Csaba Hruska
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210608/3ec40cad/attachment.html>

From csaba.hruska at gmail.com  Tue Jun  8 21:34:25 2021
From: csaba.hruska at gmail.com (Csaba Hruska)
Date: Tue, 8 Jun 2021 23:34:25 +0200
Subject: abstract interpreter for GHC Core or STG
In-Reply-To: <CAHYVw0yybcxbbbM24Y3UumsDBCeP4weNG1GhJNphRmsRw+s9tQ@mail.gmail.com>
References: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>
 <AM5PR83MB0353865361845110ADC9E73EAD379@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <CAHYVw0yybcxbbbM24Y3UumsDBCeP4weNG1GhJNphRmsRw+s9tQ@mail.gmail.com>
Message-ID: <CANjChEqVGQE9Ob+b7j8Pne5jeSkKv1x3rWL-HhQ4bcO_maxRfg@mail.gmail.com>

Cmm is too low level, I've implemented the primops in haskell in a high
level way, including the out of line primops with the rts related parts
(scheduler, io manager).
see:
https://github.com/grin-compiler/ghc-whole-program-compiler-project/blob/master/external-stg-interpreter/lib/Stg/Interpreter/ThreadScheduler.hs
https://github.com/grin-compiler/ghc-whole-program-compiler-project/tree/master/external-stg-interpreter/lib/Stg/Interpreter/PrimOp

STM is still missing though, but IMO it would be similar to
concurrency/exception related primops.
Regarding the ghcjs STM implementation, IMO the primops needs to be
implemented at least in Haskell in a pure way with ADTs to be easy for
reasoning.
But thanks for the reference.

Currently, I'm in the design phase. I.e. I need to design the abstract
domain of the STG machine values.

If this approach succeeds then it would be interesting to apply the
calculating correct compilers method on the stg interpreter to get a
compiler form it.
With this level of automation it would be extremely easy to support new
target platforms, because the RTS would be generated automatically.

On Tue, Jun 8, 2021 at 10:51 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> The stm impl In ghcjs might be a helpful comparative example on that
> front.
>
> Though I guess more broadly does this necessitate having a model of the
> Cmm semantics for the out of line primops ?
>
> On Tue, Jun 8, 2021 at 5:10 AM Simon Peyton Jones via ghc-devs <
> ghc-devs at haskell.org> wrote:
>
>> I wonder if there was an attempt in the past to create an abstract
>> interpreter for GHC Core or STG to approximate the program runtime
>> behaviour?
>>
>>
>>
>> No, not that I know of.   Because of all the primops, concurrency, STM,
>> etc, it would be something of a challenge.  The AAM story could be
>> interesting…
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Csaba
>> Hruska
>> *Sent:* 07 June 2021 15:18
>> *To:* GHC developers <ghc-devs at haskell.org>
>> *Subject:* abstract interpreter for GHC Core or STG
>>
>>
>>
>> Hello,
>>
>>
>>
>> I wonder if there was an attempt in the past to create an abstract
>> interpreter for GHC Core or STG to approximate the program runtime
>> behaviour?
>>
>> I'm curious because I'd like to turn my external STG interterpreter to an
>> abstract interpreter using the AAM (Abstracting Abstract Machines) method.
>>
>> This approach seems promising to me because a single Haskell code base
>> (ext STG interpreter) could be the specification of the Haskell operational
>> semantics and also be a detailed static analyzer that could help
>> optimization transformations.
>>
>> I'm interested in any attempt that happened during GHC/Haskell evolution.
>>
>>
>>
>> Regards,
>>
>> Csaba Hruska
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210608/2bfd5e5f/attachment.html>

From carter.schonwald at gmail.com  Tue Jun  8 22:21:45 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 8 Jun 2021 18:21:45 -0400
Subject: abstract interpreter for GHC Core or STG
In-Reply-To: <CANjChEqVGQE9Ob+b7j8Pne5jeSkKv1x3rWL-HhQ4bcO_maxRfg@mail.gmail.com>
References: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>
 <AM5PR83MB0353865361845110ADC9E73EAD379@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <CAHYVw0yybcxbbbM24Y3UumsDBCeP4weNG1GhJNphRmsRw+s9tQ@mail.gmail.com>
 <CANjChEqVGQE9Ob+b7j8Pne5jeSkKv1x3rWL-HhQ4bcO_maxRfg@mail.gmail.com>
Message-ID: <CAHYVw0x2Be-PEiSKRXP4Cm4ExzbV+CB+1BiVeDaUxL+Rx+58TA@mail.gmail.com>

How would this be used to generate the rts automatically? I’m intrigued /
would like to understand what you’re envisioning design wise for that leg.

On Tue, Jun 8, 2021 at 5:34 PM Csaba Hruska <csaba.hruska at gmail.com> wrote:

> Cmm is too low level, I've implemented the primops in haskell in a high
> level way, including the out of line primops with the rts related parts
> (scheduler, io manager).
> see:
>
> https://github.com/grin-compiler/ghc-whole-program-compiler-project/blob/master/external-stg-interpreter/lib/Stg/Interpreter/ThreadScheduler.hs
>
> https://github.com/grin-compiler/ghc-whole-program-compiler-project/tree/master/external-stg-interpreter/lib/Stg/Interpreter/PrimOp
>
> STM is still missing though, but IMO it would be similar to
> concurrency/exception related primops.
> Regarding the ghcjs STM implementation, IMO the primops needs to be
> implemented at least in Haskell in a pure way with ADTs to be easy for
> reasoning.
> But thanks for the reference.
>
> Currently, I'm in the design phase. I.e. I need to design the abstract
> domain of the STG machine values.
>
> If this approach succeeds then it would be interesting to apply the
> calculating correct compilers method on the stg interpreter to get a
> compiler form it.
> With this level of automation it would be extremely easy to support new
> target platforms, because the RTS would be generated automatically.
>
> On Tue, Jun 8, 2021 at 10:51 PM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> The stm impl In ghcjs might be a helpful comparative example on that
>> front.
>>
>> Though I guess more broadly does this necessitate having a model of the
>> Cmm semantics for the out of line primops ?
>>
>> On Tue, Jun 8, 2021 at 5:10 AM Simon Peyton Jones via ghc-devs <
>> ghc-devs at haskell.org> wrote:
>>
>>> I wonder if there was an attempt in the past to create an abstract
>>> interpreter for GHC Core or STG to approximate the program runtime
>>> behaviour?
>>>
>>>
>>>
>>> No, not that I know of.   Because of all the primops, concurrency, STM,
>>> etc, it would be something of a challenge.  The AAM story could be
>>> interesting…
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Csaba
>>> Hruska
>>> *Sent:* 07 June 2021 15:18
>>> *To:* GHC developers <ghc-devs at haskell.org>
>>> *Subject:* abstract interpreter for GHC Core or STG
>>>
>>>
>>>
>>> Hello,
>>>
>>>
>>>
>>> I wonder if there was an attempt in the past to create an abstract
>>> interpreter for GHC Core or STG to approximate the program runtime
>>> behaviour?
>>>
>>> I'm curious because I'd like to turn my external STG interterpreter to
>>> an abstract interpreter using the AAM (Abstracting Abstract Machines)
>>> method.
>>>
>>> This approach seems promising to me because a single Haskell code base
>>> (ext STG interpreter) could be the specification of the Haskell operational
>>> semantics and also be a detailed static analyzer that could help
>>> optimization transformations.
>>>
>>> I'm interested in any attempt that happened during GHC/Haskell evolution.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Csaba Hruska
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210608/626fd35b/attachment.html>

From csaba.hruska at gmail.com  Tue Jun  8 22:26:14 2021
From: csaba.hruska at gmail.com (Csaba Hruska)
Date: Wed, 9 Jun 2021 00:26:14 +0200
Subject: abstract interpreter for GHC Core or STG
In-Reply-To: <CAHYVw0x2Be-PEiSKRXP4Cm4ExzbV+CB+1BiVeDaUxL+Rx+58TA@mail.gmail.com>
References: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>
 <AM5PR83MB0353865361845110ADC9E73EAD379@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <CAHYVw0yybcxbbbM24Y3UumsDBCeP4weNG1GhJNphRmsRw+s9tQ@mail.gmail.com>
 <CANjChEqVGQE9Ob+b7j8Pne5jeSkKv1x3rWL-HhQ4bcO_maxRfg@mail.gmail.com>
 <CAHYVw0x2Be-PEiSKRXP4Cm4ExzbV+CB+1BiVeDaUxL+Rx+58TA@mail.gmail.com>
Message-ID: <CANjChErVXVH1F-76Zg4WdZ=U7m5AG8=uChJTUj-r7eubm+-T-Q@mail.gmail.com>

The external STG interpreter implements the RTS semantics and features, so
if we apply the calculating correct compiler method to the external STG
interpreter code then we should get an IR that will include the RTS code
also.

On Wed, Jun 9, 2021 at 12:21 AM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> How would this be used to generate the rts automatically? I’m intrigued /
> would like to understand what you’re envisioning design wise for that leg.
>
> On Tue, Jun 8, 2021 at 5:34 PM Csaba Hruska <csaba.hruska at gmail.com>
> wrote:
>
>> Cmm is too low level, I've implemented the primops in haskell in a high
>> level way, including the out of line primops with the rts related parts
>> (scheduler, io manager).
>> see:
>>
>> https://github.com/grin-compiler/ghc-whole-program-compiler-project/blob/master/external-stg-interpreter/lib/Stg/Interpreter/ThreadScheduler.hs
>>
>> https://github.com/grin-compiler/ghc-whole-program-compiler-project/tree/master/external-stg-interpreter/lib/Stg/Interpreter/PrimOp
>>
>> STM is still missing though, but IMO it would be similar to
>> concurrency/exception related primops.
>> Regarding the ghcjs STM implementation, IMO the primops needs to be
>> implemented at least in Haskell in a pure way with ADTs to be easy for
>> reasoning.
>> But thanks for the reference.
>>
>> Currently, I'm in the design phase. I.e. I need to design the abstract
>> domain of the STG machine values.
>>
>> If this approach succeeds then it would be interesting to apply the
>> calculating correct compilers method on the stg interpreter to get a
>> compiler form it.
>> With this level of automation it would be extremely easy to support new
>> target platforms, because the RTS would be generated automatically.
>>
>> On Tue, Jun 8, 2021 at 10:51 PM Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> The stm impl In ghcjs might be a helpful comparative example on that
>>> front.
>>>
>>> Though I guess more broadly does this necessitate having a model of the
>>> Cmm semantics for the out of line primops ?
>>>
>>> On Tue, Jun 8, 2021 at 5:10 AM Simon Peyton Jones via ghc-devs <
>>> ghc-devs at haskell.org> wrote:
>>>
>>>> I wonder if there was an attempt in the past to create an abstract
>>>> interpreter for GHC Core or STG to approximate the program runtime
>>>> behaviour?
>>>>
>>>>
>>>>
>>>> No, not that I know of.   Because of all the primops, concurrency, STM,
>>>> etc, it would be something of a challenge.  The AAM story could be
>>>> interesting…
>>>>
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Csaba
>>>> Hruska
>>>> *Sent:* 07 June 2021 15:18
>>>> *To:* GHC developers <ghc-devs at haskell.org>
>>>> *Subject:* abstract interpreter for GHC Core or STG
>>>>
>>>>
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> I wonder if there was an attempt in the past to create an abstract
>>>> interpreter for GHC Core or STG to approximate the program runtime
>>>> behaviour?
>>>>
>>>> I'm curious because I'd like to turn my external STG interterpreter to
>>>> an abstract interpreter using the AAM (Abstracting Abstract Machines)
>>>> method.
>>>>
>>>> This approach seems promising to me because a single Haskell code base
>>>> (ext STG interpreter) could be the specification of the Haskell operational
>>>> semantics and also be a detailed static analyzer that could help
>>>> optimization transformations.
>>>>
>>>> I'm interested in any attempt that happened during GHC/Haskell
>>>> evolution.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Csaba Hruska
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210609/b541b537/attachment.html>

From matthewtpickering at gmail.com  Wed Jun  9 10:29:47 2021
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 9 Jun 2021 11:29:47 +0100
Subject: Anyone ever wondered what our favourite merge bot is up to?
Message-ID: <CALuQ0m8pB3=ppP5k1TOho4W4+ejaEprU6XUG4y2BgDEJUXWYdQ@mail.gmail.com>

Hi all,

I added a new dashboard on grafana which exposes some of the systemd
logs from marge-bot.

https://grafana.gitlab.haskell.org/d/iiCppweMz/marge-bot?orgId=2&refresh=5m

You can use the logs to see why marge doesn't want to merge your MR or
whether she is dead.

Cheers,

Matt

From lists at richarde.dev  Wed Jun  9 23:11:19 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Wed, 9 Jun 2021 23:11:19 +0000
Subject: Anyone ever wondered what our favourite merge bot is up to?
In-Reply-To: <CALuQ0m8pB3=ppP5k1TOho4W4+ejaEprU6XUG4y2BgDEJUXWYdQ@mail.gmail.com>
References: <CALuQ0m8pB3=ppP5k1TOho4W4+ejaEprU6XUG4y2BgDEJUXWYdQ@mail.gmail.com>
Message-ID: <010f0179f30b5e56-6a9f4454-1055-4dec-ad88-755236a3cc8e-000000@us-east-2.amazonses.com>

This sounds fantastic!

But when I visit that page, I see the attached, which does not appear to have much information. Am I doing something wrong?

Thanks,
Richard



> On Jun 9, 2021, at 6:29 AM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
> 
> Hi all,
> 
> I added a new dashboard on grafana which exposes some of the systemd
> logs from marge-bot.
> 
> https://grafana.gitlab.haskell.org/d/iiCppweMz/marge-bot?orgId=2&refresh=5m
> 
> You can use the logs to see why marge doesn't want to merge your MR or
> whether she is dead.
> 
> Cheers,
> 
> Matt
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210609/7322a156/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: marge.png
Type: image/png
Size: 48152 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210609/7322a156/attachment.png>

From matthewtpickering at gmail.com  Thu Jun 10 05:16:22 2021
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Thu, 10 Jun 2021 06:16:22 +0100
Subject: Anyone ever wondered what our favourite merge bot is up to?
In-Reply-To: <010f0179f30b5e56-6a9f4454-1055-4dec-ad88-755236a3cc8e-000000@us-east-2.amazonses.com>
References: <CALuQ0m8pB3=ppP5k1TOho4W4+ejaEprU6XUG4y2BgDEJUXWYdQ@mail.gmail.com>
 <010f0179f30b5e56-6a9f4454-1055-4dec-ad88-755236a3cc8e-000000@us-east-2.amazonses.com>
Message-ID: <CALuQ0m8Qiof9F1BQn_VsnpHT+3=emxE1rZ=9yXoWWyvFPJrU+g@mail.gmail.com>

There are just no logs from the last 3 hours, the default time period. I
have increased the default now to 24hrs.

On Thu, Jun 10, 2021 at 12:11 AM Richard Eisenberg <lists at richarde.dev>
wrote:

> This sounds fantastic!
>
> But when I visit that page, I see the attached, which does not appear to
> have much information. Am I doing something wrong?
>
> Thanks,
> Richard
>
>
> On Jun 9, 2021, at 6:29 AM, Matthew Pickering <matthewtpickering at gmail.com>
> wrote:
>
> Hi all,
>
> I added a new dashboard on grafana which exposes some of the systemd
> logs from marge-bot.
>
> https://grafana.gitlab.haskell.org/d/iiCppweMz/marge-bot?orgId=2&refresh=5m
>
> You can use the logs to see why marge doesn't want to merge your MR or
> whether she is dead.
>
> Cheers,
>
> Matt
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210610/6df6dc44/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: marge.png
Type: image/png
Size: 48152 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210610/6df6dc44/attachment-0001.png>

From vladislav at serokell.io  Thu Jun 10 15:39:31 2021
From: vladislav at serokell.io (Vladislav Zavialov)
Date: Thu, 10 Jun 2021 18:39:31 +0300
Subject: Anyone ever wondered what our favourite merge bot is up to?
In-Reply-To: <CALuQ0m8pB3=ppP5k1TOho4W4+ejaEprU6XUG4y2BgDEJUXWYdQ@mail.gmail.com>
References: <CALuQ0m8pB3=ppP5k1TOho4W4+ejaEprU6XUG4y2BgDEJUXWYdQ@mail.gmail.com>
Message-ID: <DB257DEE-56BD-4666-9A7C-CBFB43040B6F@serokell.io>

That’s going to be very helpful, thank you! What do you think of adding this link to https://gitlab.haskell.org/marge-bot? This way it’ll be more discoverable.

- Vlad

> On 9 Jun 2021, at 13:29, Matthew Pickering <matthewtpickering at gmail.com> wrote:
> 
> Hi all,
> 
> I added a new dashboard on grafana which exposes some of the systemd
> logs from marge-bot.
> 
> https://grafana.gitlab.haskell.org/d/iiCppweMz/marge-bot?orgId=2&refresh=5m
> 
> You can use the logs to see why marge doesn't want to merge your MR or
> whether she is dead.
> 
> Cheers,
> 
> Matt
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From csaba.hruska at gmail.com  Mon Jun 14 10:38:59 2021
From: csaba.hruska at gmail.com (Csaba Hruska)
Date: Mon, 14 Jun 2021 12:38:59 +0200
Subject: abstract interpreter for GHC Core or STG
In-Reply-To: <CANjChErVXVH1F-76Zg4WdZ=U7m5AG8=uChJTUj-r7eubm+-T-Q@mail.gmail.com>
References: <CANjChEoxEr7GqAaSG6mkgfpU8sEwb14c0FZOrkJGJTbROGG2UA@mail.gmail.com>
 <AM5PR83MB0353865361845110ADC9E73EAD379@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <CAHYVw0yybcxbbbM24Y3UumsDBCeP4weNG1GhJNphRmsRw+s9tQ@mail.gmail.com>
 <CANjChEqVGQE9Ob+b7j8Pne5jeSkKv1x3rWL-HhQ4bcO_maxRfg@mail.gmail.com>
 <CAHYVw0x2Be-PEiSKRXP4Cm4ExzbV+CB+1BiVeDaUxL+Rx+58TA@mail.gmail.com>
 <CANjChErVXVH1F-76Zg4WdZ=U7m5AG8=uChJTUj-r7eubm+-T-Q@mail.gmail.com>
Message-ID: <CANjChEr6Qa4byVM=NxMzbXKE=b+qTjt0P45LTdSRd5KKNcTu4Q@mail.gmail.com>

IMO supercompilation is related to abstract interpretation. In fact an
abstract interpreter can behave as a concrete interpreter until multiple
program states merge into a single state. In that case the interpreter has
to give up precision and introduce abstract values. This technique is
called abstract counting, see:
https://matt.might.net/papers/might2006gcfa.pdf
So it seems that GHC's supercompiler related work is relevant to what I'd
like to do. (i.e. Supercompilation by Evaluation
<https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/supercomp-by-eval.pdf>
)
What primops and RTS/FFI features were supported by the GHC Core
supercompiler?

On Wed, Jun 9, 2021 at 12:26 AM Csaba Hruska <csaba.hruska at gmail.com> wrote:

> The external STG interpreter implements the RTS semantics and features, so
> if we apply the calculating correct compiler method to the external STG
> interpreter code then we should get an IR that will include the RTS code
> also.
>
> On Wed, Jun 9, 2021 at 12:21 AM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> How would this be used to generate the rts automatically? I’m intrigued /
>> would like to understand what you’re envisioning design wise for that leg.
>>
>> On Tue, Jun 8, 2021 at 5:34 PM Csaba Hruska <csaba.hruska at gmail.com>
>> wrote:
>>
>>> Cmm is too low level, I've implemented the primops in haskell in a high
>>> level way, including the out of line primops with the rts related parts
>>> (scheduler, io manager).
>>> see:
>>>
>>> https://github.com/grin-compiler/ghc-whole-program-compiler-project/blob/master/external-stg-interpreter/lib/Stg/Interpreter/ThreadScheduler.hs
>>>
>>> https://github.com/grin-compiler/ghc-whole-program-compiler-project/tree/master/external-stg-interpreter/lib/Stg/Interpreter/PrimOp
>>>
>>> STM is still missing though, but IMO it would be similar to
>>> concurrency/exception related primops.
>>> Regarding the ghcjs STM implementation, IMO the primops needs to be
>>> implemented at least in Haskell in a pure way with ADTs to be easy for
>>> reasoning.
>>> But thanks for the reference.
>>>
>>> Currently, I'm in the design phase. I.e. I need to design the abstract
>>> domain of the STG machine values.
>>>
>>> If this approach succeeds then it would be interesting to apply the
>>> calculating correct compilers method on the stg interpreter to get a
>>> compiler form it.
>>> With this level of automation it would be extremely easy to support new
>>> target platforms, because the RTS would be generated automatically.
>>>
>>> On Tue, Jun 8, 2021 at 10:51 PM Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> The stm impl In ghcjs might be a helpful comparative example on that
>>>> front.
>>>>
>>>> Though I guess more broadly does this necessitate having a model of the
>>>> Cmm semantics for the out of line primops ?
>>>>
>>>> On Tue, Jun 8, 2021 at 5:10 AM Simon Peyton Jones via ghc-devs <
>>>> ghc-devs at haskell.org> wrote:
>>>>
>>>>> I wonder if there was an attempt in the past to create an abstract
>>>>> interpreter for GHC Core or STG to approximate the program runtime
>>>>> behaviour?
>>>>>
>>>>>
>>>>>
>>>>> No, not that I know of.   Because of all the primops, concurrency,
>>>>> STM, etc, it would be something of a challenge.  The AAM story could be
>>>>> interesting…
>>>>>
>>>>>
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Csaba
>>>>> Hruska
>>>>> *Sent:* 07 June 2021 15:18
>>>>> *To:* GHC developers <ghc-devs at haskell.org>
>>>>> *Subject:* abstract interpreter for GHC Core or STG
>>>>>
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>> I wonder if there was an attempt in the past to create an abstract
>>>>> interpreter for GHC Core or STG to approximate the program runtime
>>>>> behaviour?
>>>>>
>>>>> I'm curious because I'd like to turn my external STG interterpreter to
>>>>> an abstract interpreter using the AAM (Abstracting Abstract Machines)
>>>>> method.
>>>>>
>>>>> This approach seems promising to me because a single Haskell code base
>>>>> (ext STG interpreter) could be the specification of the Haskell operational
>>>>> semantics and also be a detailed static analyzer that could help
>>>>> optimization transformations.
>>>>>
>>>>> I'm interested in any attempt that happened during GHC/Haskell
>>>>> evolution.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Csaba Hruska
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210614/463abc2d/attachment.html>

From ben at well-typed.com  Tue Jun 15 12:19:36 2021
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 15 Jun 2021 08:19:36 -0400
Subject: CI Status Update
Message-ID: <87czsnz5ey.fsf@smart-cactus.org>

Hi all,

As you may have realized, CI has been a bit of disaster over the last
few days. It appears that this is just the most recent chapter in our
on-going troubles with Docker image storage, being due to an outage of
our upstream storage service [1]. Davean and I have started to implement
a plan to migrate away from DreamObjects back to local storage.
Unfortunately to complete this migration we need DreamObjects to come
back online; I am currently waiting until this occurs. Further updates
will come as the situation develops.

Cheers,

- Ben

[1] https://www.dreamhoststatus.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210615/da52c232/attachment.sig>

From jwstolarek at gmail.com  Tue Jun 15 13:18:34 2021
From: jwstolarek at gmail.com (Janek Stolarek)
Date: Tue, 15 Jun 2021 14:18:34 +0100
Subject: GHC and the future of Freenode
In-Reply-To: <4dda71eb-3a8e-51f0-e080-91ad91b92b32@obsidian.systems>
References: <877djuanm3.fsf@smart-cactus.org>
 <CAKFCL4WANkbpq0P7_4R4F6Y1_-cqU76cEQ4sQMO65-LeC3HMCw@mail.gmail.com>
 <4dda71eb-3a8e-51f0-e080-91ad91b92b32@obsidian.systems>
Message-ID: <202106151418.34334.jwstolarek@gmail.com>

Apparently, Freenode deleted all registered users and channels several hours ago:

https://old.reddit.com/r/linux/comments/o0263h/all_freenode_channels_and_users_gone/

A more detailed explanation/speculation on what's goin on:

https://www.devever.net/~hl/freenode_suicide

Janek

From sam.derbyshire at gmail.com  Tue Jun 15 19:50:57 2021
From: sam.derbyshire at gmail.com (Sam Derbyshire)
Date: Tue, 15 Jun 2021 21:50:57 +0200
Subject: Rewriting plugins: request for feedback
In-Reply-To: <CAA1CnJPTysDy6mmD_hwCurvCP0k_+ORmxPeE0sR+1NWtbGKGkQ@mail.gmail.com>
References: <CAA1CnJPTysDy6mmD_hwCurvCP0k_+ORmxPeE0sR+1NWtbGKGkQ@mail.gmail.com>
Message-ID: <CAA1CnJNQfcDj9CsQuPiVwyJ6=60uwY78Xc_9erRbvbCH51PeUQ@mail.gmail.com>

Hi again everyone,


I've been making some more adjustments to the API of type-checking plugins.
Following a suggestion by Richard, the mechanism for reporting errors while
rewriting type family applications now consists of emitting a wanted
constraint with a custom type error message. There are several technical
reasons for this, which I will not get into.
This means there are now only two constructors of TcPluginRewriteResult:
TcPluginNoRewrite and TcPluginRewriteTo. Both of these now take an extra
argument: additional wanted constraints, which will be processed and
emitted by GHC.


Coming back to the type-checking plugin API as a whole (not just the
rewriting of type family applications), I've come to the realisation that
it is probably best to keep GHC's interface as simple as possible, to allow
library authors to write their own APIs.
After all, most of the API doesn't need to live within the GHC codebase,
and instead (in my opinion) belongs in libraries that simply import the ghc
package (which thankfully doesn't hide any exports one might want to use).
This means we don't have to tie any experimentation with type-checking
plugin APIs to the GHC release schedule.

To that end, I have concluded that one single non-backwards-compatible
change seems important: changing the TcPluginM monad from being isomorphic
to "ReaderT EvBindsVar TcM" to simply being a newtype around TcM. Then, we
instead pass an EvBindsVar as an extra argument to tcPluginSolve.
This avoids all the silly business with functions whose documentation said
"only call this within tcPluginSolve or it will cause a crash" (a situation
which was only made worse by the addition of rewriting plugins). It's also
less opinionated: library authors can use a ReaderT wrapper in their API if
they desire, but are not forced to do so.
Please note that I don't make this change lightly, as I know it is already
time-consuming enough to maintain type-checking plugins, especially as much
more significant changes abound (removal of flattening variables in GHC
9.2, removal of derived constraints (possibly in GHC 9.4)). I hope
nevertheless that you might find this acceptable.


Finally, facilitated by the above, I have started implementing a library
providing a simple API for type-checking plugins; see here
https://github.com/sheaf/ghc-tcplugin-api.
An example of a not-totally-trivial rewriting plugin is given here:
https://github.com/sheaf/ghc-tcplugin-api/blob/ad6ca964c3b27c28bb27392d7ba406cfac82176d/examples/RewriterPlugin/plugin/RewriterPlugin.hs
.
Note that I barely had to import anything from the ghc package; I hope this
can remain true for more involved plugins (up to a point).
Please let me know what you think, in particular if you think certain
important functions are missing from the API.

For this library specifically, I have added back ReaderT layers (but only
in the appropriate situations, to avoid reintroducing the aforementioned
problem with "only call this in tcPluginSolve"), and provided MTL-style
typeclasses for operations that work with multiple different phases of the
plugin.
Other design options are of course possible; at any rate, I think it is
preferable to be making these API choices outside of GHC itself whenever
possible.
I've also included helpers for creating custom type errors within
type-checking plugins, as that was unnecessarily cumbersome. (One still
needs to provide a CtLoc to inform GHC of the source location of the error;
one can get this from a constraint fed to the plugin in a solver plugin, or
from the rewriting environment in a rewriter plugin).


Note that this all still depends on the WIP GHC MR 5909, available at
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5909.


I look forward to your feedback,

Thanks,

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210615/e76e5d12/attachment.html>

From cdsmith at gmail.com  Wed Jun 16 13:38:59 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Wed, 16 Jun 2021 09:38:59 -0400
Subject: Is simplified subsumption really necessary?
Message-ID: <CAPq5Pv+CNBxA42shWao6Z+MQ4xXiWwi96Gb1eW_TxQRqiDd9rw@mail.gmail.com>

This might be in the "ship has sailed" territory, but I'd like to bring it
up anyway.
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
says:

Suppose GHC lacked all four features, and someone proposed adding them.
> That proposal would never leave the launchpad.
>

Let's test that hypothesis.

I've been spending increasing amounts of time fighting against simplified
subsumption while porting Haskell code to GHC 9.0.  It's not that any
specific instance of this problem is hard to fix; rather, it's that it
completely screws up my intuition about what should be valid Haskell.  It
doesn't help that HLS still requires 8.10.4, so I usually don't find out
I've broken my libraries for GHC 9.0 until continuous integration kicks
in.  At this point, it's become fairly routine that my code that works fine
with 8.10.4 is broken with 9.0, and this makes me sad.

Understandably, eta expansion reducing the strictness of terms is bad.  But
wouldn't it be possible to choose a desugaring with seq that doesn't do so?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210616/3635ff62/attachment.html>

From jakzale at gmail.com  Wed Jun 16 15:02:28 2021
From: jakzale at gmail.com (Jakub Zalewski)
Date: Wed, 16 Jun 2021 17:02:28 +0200
Subject: GHC and the future of Freenode
In-Reply-To: <202106151418.34334.jwstolarek@gmail.com>
Message-ID: <CC54TK4YA9AG.ERCY7T8D0QHK@MacBook-Air-Jakub.local>

On Tue Jun 15, 2021 at 3:18 PM CEST, Janek Stolarek wrote:
> Apparently, Freenode deleted all registered users and channels several
> hours ago.

I guess that should solve the problem of communities being split between
Freenode and Libera.

If I may add towards using IRC, even though it may seem archaic towards
newcomers:

- it allows them to join without registration (via web.libera.chat), and
- it allows them to use a client of their choosing (I am not aware of
  any stable Matrix clients beside Element).

>From my own experience, Electron-based clients (Element included)
consume unreasonable amounts of RAM:  Element is consuming ~700MiB of
RAM just to stay idle on my machine.  To give a fair comparison, the tab
for irccloud tends to consume ~300MiB.

-- 
Jakub

From simonpj at microsoft.com  Wed Jun 16 16:00:06 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 16 Jun 2021 16:00:06 +0000
Subject: Is simplified subsumption really necessary?
In-Reply-To: <CAPq5Pv+CNBxA42shWao6Z+MQ4xXiWwi96Gb1eW_TxQRqiDd9rw@mail.gmail.com>
References: <CAPq5Pv+CNBxA42shWao6Z+MQ4xXiWwi96Gb1eW_TxQRqiDd9rw@mail.gmail.com>
Message-ID: <AM5PR83MB03535D5EF2252800C1C66143AD0F9@AM5PR83MB0353.EURPRD83.prod.outlook.com>

rather, it's that it completely screws up my intuition about what should be valid Haskell.

I'm sorry to hear that Chris.   It's exactly backwards from what I would expect - the typing rules with simple subsumption are, well, simpler than those for complicated subsumption, and so one might hope that your intuition had fewer complexities to grapple with.

Maybe it's partly a matter of explanation and presentation.  Do you have an example of a case in which your intuition was screwed up by the simple subsumption rules?  Discussing in the abstract is often un-illuminating.

But wouldn't it be possible to choose a desugaring with seq that doesn't do so?

I just don't know how to do that.  Maybe someone else does.

Meanwhile, Quick Look<https://www.microsoft.com/en-us/research/publication/a-quick-look-at-impredicativity/> depends strongly on simple subsumption.  And I'm very keen on QL.

Simon


From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Chris Smith
Sent: 16 June 2021 14:39
To: GHC developers <ghc-devs at haskell.org>
Subject: Is simplified subsumption really necessary?

This might be in the "ship has sailed" territory, but I'd like to bring it up anyway.  https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0287-simplify-subsumption.rst&data=04%7C01%7Csimonpj%40microsoft.com%7C6e04d0f9a068432fad8108d930cc2e1e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637594475810326243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=r6RfLGB0CRXF%2FN%2FFvbu3uDoxg1i63oVXya2v6Zlqr7E%3D&reserved=0> says:

Suppose GHC lacked all four features, and someone proposed adding them. That proposal would never leave the launchpad.

Let's test that hypothesis.

I've been spending increasing amounts of time fighting against simplified subsumption while porting Haskell code to GHC 9.0.  It's not that any specific instance of this problem is hard to fix; rather, it's that it completely screws up my intuition about what should be valid Haskell.  It doesn't help that HLS still requires 8.10.4, so I usually don't find out I've broken my libraries for GHC 9.0 until continuous integration kicks in.  At this point, it's become fairly routine that my code that works fine with 8.10.4 is broken with 9.0, and this makes me sad.

Understandably, eta expansion reducing the strictness of terms is bad.  But wouldn't it be possible to choose a desugaring with seq that doesn't do so?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210616/8d7e63a2/attachment.html>

From sgraf1337 at gmail.com  Wed Jun 16 16:19:31 2021
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Wed, 16 Jun 2021 16:19:31 +0000
Subject: GHC and the future of Freenode
In-Reply-To: <CC54TK4YA9AG.ERCY7T8D0QHK@macbook-air-jakub.local>
References: <202106151418.34334.jwstolarek@gmail.com>
 <CC54TK4YA9AG.ERCY7T8D0QHK@macbook-air-jakub.local>
Message-ID: <em25b1db4b-14aa-4f2f-be42-fd8d8448be90@sebastian-pc>

Re: memory usage: I get that people don't like bloated Electron clients 
when they already run a browser instance, but fortunately, Element 
doesn't need to be run as a standalone app (*).
Well, except when you want to search encrypted history. But then you're 
out of luck with irccloud, too...

I run Element in a pinned Firefox tab, and according to its task manager 
it reports 27.4MB, which is about the same for my WhatsApp tab. It's a 
bit more than irccloud (about 20MB), but I also have quite a few chats 
in that one tab. It's also quite a lot less than every individual MR 
page of our GitLab instance (27-110MB), of which I have pinned about 
5-10 at any time, so it really doesn't matter much.

Since the Matrix<->Libera.chat bridge works now, I have next to no 
incentive to push for Matrix at the moment, although I still would 
prefer it.
All arguments have been said, so I won't repeat them. It seems like this 
discussion will go stale in time without anyone stepping up to force a 
migration. Fine with me.

Sebastian

------ Originalnachricht ------
Von: "Jakub Zalewski" <jakzale at gmail.com>
An: "Janek Stolarek" <jwstolarek at gmail.com>; ghc-devs at haskell.org
Gesendet: 16.06.2021 17:02:28
Betreff: Re: GHC and the future of Freenode

>On Tue Jun 15, 2021 at 3:18 PM CEST, Janek Stolarek wrote:
>>  Apparently, Freenode deleted all registered users and channels several
>>  hours ago.
>
>I guess that should solve the problem of communities being split between
>Freenode and Libera.
>
>If I may add towards using IRC, even though it may seem archaic towards
>newcomers:
>
>- it allows them to join without registration (via web.libera.chat), and
>- it allows them to use a client of their choosing (I am not aware of
>   any stable Matrix clients beside Element).
>
>From my own experience, Electron-based clients (Element included)
>consume unreasonable amounts of RAM:  Element is consuming ~700MiB of
>RAM just to stay idle on my machine.  To give a fair comparison, the tab
>for irccloud tends to consume ~300MiB.
>
>--
>Jakub
>_______________________________________________
>ghc-devs mailing list
>ghc-devs at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From sam.derbyshire at gmail.com  Wed Jun 16 21:03:50 2021
From: sam.derbyshire at gmail.com (Sam Derbyshire)
Date: Wed, 16 Jun 2021 23:03:50 +0200
Subject: Rewriting plugins: request for feedback
In-Reply-To: <CAA1CnJNQfcDj9CsQuPiVwyJ6=60uwY78Xc_9erRbvbCH51PeUQ@mail.gmail.com>
References: <CAA1CnJPTysDy6mmD_hwCurvCP0k_+ORmxPeE0sR+1NWtbGKGkQ@mail.gmail.com>
 <CAA1CnJNQfcDj9CsQuPiVwyJ6=60uwY78Xc_9erRbvbCH51PeUQ@mail.gmail.com>
Message-ID: <CAA1CnJPUA4vaW7X8FriJYn=he6VSG8p2j-GS=jVMzsy_=8hgjQ@mail.gmail.com>

Hey everyone,

I've put up some haddocks for this new type-checking plugin API, see here:
https://sheaf.github.io/ghc-tcplugin-api/GHC-TcPlugin-API.html.
(The page is mainly meant to be navigated using the contents pane.)

I hope this might be a more welcoming point of entry for people who are
interested in learning about GHC typechecker plugins.

Let me know what you think,

Thanks,

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210616/e7be59f7/attachment.html>

From christiaan.baaij at gmail.com  Thu Jun 17 08:41:48 2021
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Thu, 17 Jun 2021 10:41:48 +0200
Subject: Rewriting plugins: request for feedback
In-Reply-To: <CAA1CnJPUA4vaW7X8FriJYn=he6VSG8p2j-GS=jVMzsy_=8hgjQ@mail.gmail.com>
References: <CAA1CnJPTysDy6mmD_hwCurvCP0k_+ORmxPeE0sR+1NWtbGKGkQ@mail.gmail.com>
 <CAA1CnJNQfcDj9CsQuPiVwyJ6=60uwY78Xc_9erRbvbCH51PeUQ@mail.gmail.com>
 <CAA1CnJPUA4vaW7X8FriJYn=he6VSG8p2j-GS=jVMzsy_=8hgjQ@mail.gmail.com>
Message-ID: <CABzw7bUqrkij=GT7P-yWqz=9Cph4jgLLnrMhSGcib7-g2P_OFg@mail.gmail.com>

Hi Sam,

Thanks for picking this up, the API looks good so far.
I'll try to port our https://hackage.haskell.org/package/ghc-typelits-extra
package to the new API.

Though first I need to upgrade
https://hackage.haskell.org/package/ghc-typelits-natnormalise to the GHC
9.2+ API,
which is got somewhat more complicated than usual GHC upgrades due to a
change in representation of (<=? :: Nat -> Nat -> Bool) in
https://gitlab.haskell.org/ghc/ghc/-/commit/eea96042f1e8682605ae68db10f2bcdd7dab923e

I'll report back any issues I encounter if/when I encounter any.

Cheers,

Christiaan


On Wed, 16 Jun 2021 at 23:04, Sam Derbyshire <sam.derbyshire at gmail.com>
wrote:

> Hey everyone,
>
> I've put up some haddocks for this new type-checking plugin API, see here:
> https://sheaf.github.io/ghc-tcplugin-api/GHC-TcPlugin-API.html.
> (The page is mainly meant to be navigated using the contents pane.)
>
> I hope this might be a more welcoming point of entry for people who are
> interested in learning about GHC typechecker plugins.
>
> Let me know what you think,
>
> Thanks,
>
> Sam
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210617/f3c90475/attachment.html>

From christiaan.baaij at gmail.com  Thu Jun 17 09:43:33 2021
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Thu, 17 Jun 2021 11:43:33 +0200
Subject: Error message degradation for (<= :: Nat -> Nat -> Constraint) in GHC
 9.2+
Message-ID: <CABzw7bVr9Wj3r0QLtw4Nwc4D+n=vhdhF1uEEwHmMDGZDixbXnw@mail.gmail.com>

Hi Ghc-Devs,

When upgrading one of our tc plugins
https://hackage.haskell.org/package/ghc-typelits-natnormalise to GHC 9.2,
one of our tests, repeated here:

```
{-# LANGUAGE DataKinds, TypeFamilies, TypeOperators #-}
module TestInEq where

import Data.Proxy
import GHC.TypeLits

proxyInEq :: (a <= b) => Proxy a -> Proxy b -> ()
proxyInEq _ _ = ()

proxyInEq1 :: Proxy a -> Proxy (a+1) -> ()
proxyInEq1 = proxyInEq
```

degraded quite badly in terms of the error message.
Where in GHC 9.0.1 we get:

```
TestInEq.hs:11:14: error:
    • Couldn't match type ‘a <=? (a + 1)’ with ‘'True’
        arising from a use of ‘proxyInEq’
    • In the expression: proxyInEq
      In an equation for ‘proxyInEq1’: proxyInEq1 = proxyInEq
    • Relevant bindings include
        proxyInEq1 :: Proxy a -> Proxy (a + 1) -> ()
          (bound at TestInEq.hs:11:1)
   |
11 | proxyInEq1 = proxyInEq
   |
```

with GHC 9.2.0.20210422 we get:

```
TestInEq.hs:11:14: error:
    • Couldn't match type ‘Data.Type.Ord.OrdCond
                             (CmpNat a (a + 1)) 'True 'True 'False’
                     with ‘'True’
        arising from a use of ‘proxyInEq’
    • In the expression: proxyInEq
      In an equation for ‘proxyInEq1’: proxyInEq1 = proxyInEq
    • Relevant bindings include
        proxyInEq1 :: Proxy a -> Proxy (a + 1) -> ()
          (bound at TestInEq.hs:11:1)
   |
11 | proxyInEq1 = proxyInEq
   |
```

Errors messages involving type-level naturals and their operations already
weren't the poster-child of comprehensable GHC error messages, but this
change has made the situation worse in my opinion.

This change in error message is due to:
https://gitlab.haskell.org/ghc/ghc/-/commit/eea96042f1e8682605ae68db10f2bcdd7dab923e

Is there a way we can get the nicer pre-9.2.0.2021 error message again
before the proper 9.2.1 release?
e.g. by doing one of the following:
1. Reinstate `(<=? :: Nat -> Nat -> Bool)` as a builtin type family
2. Somehow add a custom type-error to `Data.Type.Ord.OrdCond`
3. Don't expand type aliases in type errors

What do you think? should this be fixed? should this be fixed before the
9.2.1 release?

-- Christiaan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210617/bbf06840/attachment.html>

From sam.derbyshire at gmail.com  Thu Jun 17 12:37:46 2021
From: sam.derbyshire at gmail.com (Sam Derbyshire)
Date: Thu, 17 Jun 2021 14:37:46 +0200
Subject: Error message degradation for (<= :: Nat -> Nat -> Constraint) in
 GHC 9.2+
In-Reply-To: <CABzw7bVr9Wj3r0QLtw4Nwc4D+n=vhdhF1uEEwHmMDGZDixbXnw@mail.gmail.com>
References: <CABzw7bVr9Wj3r0QLtw4Nwc4D+n=vhdhF1uEEwHmMDGZDixbXnw@mail.gmail.com>
Message-ID: <CAA1CnJMDEeaTijV0nW99YZmpFQhXm33rTGQNJkX1dZX86VBYag@mail.gmail.com>

Hi Christiaan,

As far as I'm concerned that's a worrying regression, and I think you
should file a ticket on the GHC tracker about it.
I believe GHC already contains logic to avoid expanding type synonyms in
error messages in certain situations, but it apparently doesn't apply here.
Hopefully someone more knowledgeable about this can chime in.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210617/f6450e35/attachment.html>

From adam at well-typed.com  Thu Jun 17 12:46:42 2021
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 17 Jun 2021 13:46:42 +0100
Subject: Error message degradation for (<= :: Nat -> Nat -> Constraint) in
 GHC 9.2+
In-Reply-To: <CABzw7bVr9Wj3r0QLtw4Nwc4D+n=vhdhF1uEEwHmMDGZDixbXnw@mail.gmail.com>
References: <CABzw7bVr9Wj3r0QLtw4Nwc4D+n=vhdhF1uEEwHmMDGZDixbXnw@mail.gmail.com>
Message-ID: <b6a0390b-889f-36ea-2a01-1e5ede45eb6f@well-typed.com>

Hi Christiaan,


On 17/06/2021 10:43, Christiaan Baaij wrote:
> [...]
> 
> Errors messages involving type-level naturals and their operations
> already weren't the poster-child of comprehensable GHC error messages,
> but this change has made the situation worse in my opinion.
> 
> This change in error message is due to:
> https://gitlab.haskell.org/ghc/ghc/-/commit/eea96042f1e8682605ae68db10f2bcdd7dab923e
> <https://gitlab.haskell.org/ghc/ghc/-/commit/eea96042f1e8682605ae68db10f2bcdd7dab923e>
> 
> Is there a way we can get the nicer pre-9.2.0.2021 error message again
> before the proper 9.2.1 release?
> e.g. by doing one of the following:
> 1. Reinstate `(<=? :: Nat -> Nat -> Bool)` as a builtin type family
> 2. Somehow add a custom type-error to `Data.Type.Ord.OrdCond`
> 3. Don't expand type aliases in type errors
> 
> What do you think? should this be fixed? should this be fixed before the
> 9.2.1 release?

I don't know the context for this change or the immediate feasibility of
1, but regarding the other two points:

GHC does in general try to avoid expanding type aliases if it doesn't
need to (but it does expand type families). The difficulty here is that
the constraint solver must expand the synonym to see if the constraint
can be solved, and it seems hard (though perhaps not impossible) to keep
track of the original forms of constraints as they get simplified by the
solver.

Presumably it wouldn't be terribly difficult to add some built-in magic
to GHC's error message printing machinery that looked through types for
occurrences of specific patterns (like OrdCond with concrete arguments)
and replaced them with simpler versions. It would be really nice,
though, to have a way to specify this as a user, rather than it being
limited to built-in magic.

I'm imagining having a pragma to mark type synonyms as "contractible",
then when showing a type, GHC would try to match it against the RHSs of
contractible synonyms in scope. If there are multiple matches, probably
it should pick the most specific; I'm not sure if we should have some
other mechanism for prioritization or if we should just accept arbitrary
choices where there is overlap.

Does this sound useful to others? I think it could be really helpful for
improving type error messages. It won't be in 9.2 though...

Best wishes,

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
118 Wymering Mansions, Wymering Road, London W9 2NF, England

From christiaan.baaij at gmail.com  Thu Jun 17 13:06:36 2021
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Thu, 17 Jun 2021 15:06:36 +0200
Subject: Error message degradation for (<= :: Nat -> Nat -> Constraint) in
 GHC 9.2+
In-Reply-To: <b6a0390b-889f-36ea-2a01-1e5ede45eb6f@well-typed.com>
References: <CABzw7bVr9Wj3r0QLtw4Nwc4D+n=vhdhF1uEEwHmMDGZDixbXnw@mail.gmail.com>
 <b6a0390b-889f-36ea-2a01-1e5ede45eb6f@well-typed.com>
Message-ID: <CABzw7bXK=icECEfM3XVHWKNjn-SviCrFHi_TbajZLDHPoVWpsg@mail.gmail.com>

I imagined solution 1. as:

1. reinstate the magic type family `(<=?) :: Nat -> Nat -> Bool` in
GHC.TypeNats
```
module GHC.TypeNats where

type family (m :: Nat) <=? (n :: Nat) :: Bool
```

2. instead of exporting the following type alias from Data.Type.Ord
```
type (<=?) :: k -> k -> Bool
type m <=? n = OrdCond (Compare m n) 'True 'True 'False
```

do:

```
import qualified GHC.TypeNats as T

type (<=?) :: forall k . k -> k -> Bool
type family (<=?) a b where
  (<=?) (a :: T.Nat) b = (T.<=?) a b
  (<=?) a b            = OrdCond (Compare a b) 'True 'True 'False
```

I realize this is far from ideal

On Thu, 17 Jun 2021 at 14:46, Adam Gundry <adam at well-typed.com> wrote:

> Hi Christiaan,
>
>
> On 17/06/2021 10:43, Christiaan Baaij wrote:
> > [...]
> >
> > Errors messages involving type-level naturals and their operations
> > already weren't the poster-child of comprehensable GHC error messages,
> > but this change has made the situation worse in my opinion.
> >
> > This change in error message is due to:
> >
> https://gitlab.haskell.org/ghc/ghc/-/commit/eea96042f1e8682605ae68db10f2bcdd7dab923e
> > <
> https://gitlab.haskell.org/ghc/ghc/-/commit/eea96042f1e8682605ae68db10f2bcdd7dab923e
> >
> >
> > Is there a way we can get the nicer pre-9.2.0.2021 error message again
> > before the proper 9.2.1 release?
> > e.g. by doing one of the following:
> > 1. Reinstate `(<=? :: Nat -> Nat -> Bool)` as a builtin type family
> > 2. Somehow add a custom type-error to `Data.Type.Ord.OrdCond`
> > 3. Don't expand type aliases in type errors
> >
> > What do you think? should this be fixed? should this be fixed before the
> > 9.2.1 release?
>
> I don't know the context for this change or the immediate feasibility of
> 1, but regarding the other two points:
>
> GHC does in general try to avoid expanding type aliases if it doesn't
> need to (but it does expand type families). The difficulty here is that
> the constraint solver must expand the synonym to see if the constraint
> can be solved, and it seems hard (though perhaps not impossible) to keep
> track of the original forms of constraints as they get simplified by the
> solver.
>
> Presumably it wouldn't be terribly difficult to add some built-in magic
> to GHC's error message printing machinery that looked through types for
> occurrences of specific patterns (like OrdCond with concrete arguments)
> and replaced them with simpler versions. It would be really nice,
> though, to have a way to specify this as a user, rather than it being
> limited to built-in magic.
>
> I'm imagining having a pragma to mark type synonyms as "contractible",
> then when showing a type, GHC would try to match it against the RHSs of
> contractible synonyms in scope. If there are multiple matches, probably
> it should pick the most specific; I'm not sure if we should have some
> other mechanism for prioritization or if we should just accept arbitrary
> choices where there is overlap.
>
> Does this sound useful to others? I think it could be really helpful for
> improving type error messages. It won't be in 9.2 though...
>
> Best wishes,
>
> Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 118 Wymering Mansions, Wymering Road, London W9 2NF, England
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210617/e7a4b27f/attachment.html>

From carter.schonwald at gmail.com  Thu Jun 17 15:09:32 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 17 Jun 2021 11:09:32 -0400
Subject: Error message degradation for (<= :: Nat -> Nat -> Constraint) in
 GHC 9.2+
In-Reply-To: <CAA1CnJMDEeaTijV0nW99YZmpFQhXm33rTGQNJkX1dZX86VBYag@mail.gmail.com>
References: <CABzw7bVr9Wj3r0QLtw4Nwc4D+n=vhdhF1uEEwHmMDGZDixbXnw@mail.gmail.com>
 <CAA1CnJMDEeaTijV0nW99YZmpFQhXm33rTGQNJkX1dZX86VBYag@mail.gmail.com>
Message-ID: <CAHYVw0wNdwW3Qxyd7QhVod6aOcFPoG5OHn17o8AWYLyvCNGxeQ@mail.gmail.com>

Agreed and better articulated than what I likely would have said

On Thu, Jun 17, 2021 at 8:38 AM Sam Derbyshire <sam.derbyshire at gmail.com>
wrote:

> Hi Christiaan,
>
> As far as I'm concerned that's a worrying regression, and I think you
> should file a ticket on the GHC tracker about it.
> I believe GHC already contains logic to avoid expanding type synonyms in
> error messages in certain situations, but it apparently doesn't apply here.
> Hopefully someone more knowledgeable about this can chime in.
>
> Sam
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210617/fc15e7bd/attachment.html>

From simonpj at microsoft.com  Thu Jun 17 16:44:12 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Jun 2021 16:44:12 +0000
Subject: Error message degradation for (<= :: Nat -> Nat -> Constraint) in
 GHC 9.2+
In-Reply-To: <CABzw7bVr9Wj3r0QLtw4Nwc4D+n=vhdhF1uEEwHmMDGZDixbXnw@mail.gmail.com>
References: <CABzw7bVr9Wj3r0QLtw4Nwc4D+n=vhdhF1uEEwHmMDGZDixbXnw@mail.gmail.com>
Message-ID: <AM5PR83MB0353860F657EFD4C956DBF8FAD0E9@AM5PR83MB0353.EURPRD83.prod.outlook.com>

Christiaan,

Do please submit a bug report on GHC's issue tracker, with a way to reproduce it.

Thanks

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Christiaan Baaij
Sent: 17 June 2021 10:44
To: ghc-devs <ghc-devs at haskell.org>
Subject: Error message degradation for (<= :: Nat -> Nat -> Constraint) in GHC 9.2+

Hi Ghc-Devs,

When upgrading one of our tc plugins https://hackage.haskell.org/package/ghc-typelits-natnormalise<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-typelits-natnormalise&data=04%7C01%7Csimonpj%40microsoft.com%7C42380a30e7f54d6ad06708d931747622%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637595199077626853%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=MDuOq05JaifjtEkq7JrdjmmwgCWEtIyZ%2BYqIFNv7FhY%3D&reserved=0> to GHC 9.2, one of our tests, repeated here:

```
{-# LANGUAGE DataKinds, TypeFamilies, TypeOperators #-}
module TestInEq where

import Data.Proxy
import GHC.TypeLits

proxyInEq :: (a <= b) => Proxy a -> Proxy b -> ()
proxyInEq _ _ = ()

proxyInEq1 :: Proxy a -> Proxy (a+1) -> ()
proxyInEq1 = proxyInEq
```

degraded quite badly in terms of the error message.
Where in GHC 9.0.1 we get:

```
TestInEq.hs:11:14: error:
    * Couldn't match type 'a <=? (a + 1)' with ''True'
        arising from a use of 'proxyInEq'
    * In the expression: proxyInEq
      In an equation for 'proxyInEq1': proxyInEq1 = proxyInEq
    * Relevant bindings include
        proxyInEq1 :: Proxy a -> Proxy (a + 1) -> ()
          (bound at TestInEq.hs:11:1)
   |
11 | proxyInEq1 = proxyInEq
   |
```

with GHC 9.2.0.20210422 we get:

```
TestInEq.hs:11:14: error:
    * Couldn't match type 'Data.Type.Ord.OrdCond
                             (CmpNat a (a + 1)) 'True 'True 'False'
                     with ''True'
        arising from a use of 'proxyInEq'
    * In the expression: proxyInEq
      In an equation for 'proxyInEq1': proxyInEq1 = proxyInEq
    * Relevant bindings include
        proxyInEq1 :: Proxy a -> Proxy (a + 1) -> ()
          (bound at TestInEq.hs:11:1)
   |
11 | proxyInEq1 = proxyInEq
   |
```

Errors messages involving type-level naturals and their operations already weren't the poster-child of comprehensable GHC error messages, but this change has made the situation worse in my opinion.

This change in error message is due to: https://gitlab.haskell.org/ghc/ghc/-/commit/eea96042f1e8682605ae68db10f2bcdd7dab923e<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fcommit%2Feea96042f1e8682605ae68db10f2bcdd7dab923e&data=04%7C01%7Csimonpj%40microsoft.com%7C42380a30e7f54d6ad06708d931747622%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637595199077636846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=FfAQaEksSYEWNjOzuOmwhPXz6lI%2F5o5LT%2Ftwbh42wFM%3D&reserved=0>

Is there a way we can get the nicer pre-9.2.0.2021 error message again before the proper 9.2.1 release?
e.g. by doing one of the following:
1. Reinstate `(<=? :: Nat -> Nat -> Bool)` as a builtin type family
2. Somehow add a custom type-error to `Data.Type.Ord.OrdCond`
3. Don't expand type aliases in type errors

What do you think? should this be fixed? should this be fixed before the 9.2.1 release?

-- Christiaan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210617/37d1d2ca/attachment.html>

From christiaan.baaij at gmail.com  Thu Jun 17 17:36:30 2021
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Thu, 17 Jun 2021 19:36:30 +0200
Subject: Error message degradation for (<= :: Nat -> Nat -> Constraint) in
 GHC 9.2+
In-Reply-To: <AM5PR83MB0353860F657EFD4C956DBF8FAD0E9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <CABzw7bVr9Wj3r0QLtw4Nwc4D+n=vhdhF1uEEwHmMDGZDixbXnw@mail.gmail.com>
 <AM5PR83MB0353860F657EFD4C956DBF8FAD0E9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <CABzw7bVZfM359XG7x3P28PkKdxJF=urbbfwC-tUViwoh7UkvHQ@mail.gmail.com>

I have reported the issue here:
https://gitlab.haskell.org/ghc/ghc/-/issues/20009

On Thu, 17 Jun 2021 at 18:44, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Christiaan,
>
>
>
> Do please submit a bug report on GHC’s issue tracker, with a way to
> reproduce it.
>
>
>
> Thanks
>
>
> Simon
>
>
>
> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Christiaan
> Baaij
> *Sent:* 17 June 2021 10:44
> *To:* ghc-devs <ghc-devs at haskell.org>
> *Subject:* Error message degradation for (<= :: Nat -> Nat -> Constraint)
> in GHC 9.2+
>
>
>
> Hi Ghc-Devs,
>
>
>
> When upgrading one of our tc plugins
> https://hackage.haskell.org/package/ghc-typelits-natnormalise
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-typelits-natnormalise&data=04%7C01%7Csimonpj%40microsoft.com%7C42380a30e7f54d6ad06708d931747622%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637595199077626853%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=MDuOq05JaifjtEkq7JrdjmmwgCWEtIyZ%2BYqIFNv7FhY%3D&reserved=0>
> to GHC 9.2, one of our tests, repeated here:
>
> ```
>
> {-# LANGUAGE DataKinds, TypeFamilies, TypeOperators #-}
> module TestInEq where
>
> import Data.Proxy
> import GHC.TypeLits
>
> proxyInEq :: (a <= b) => Proxy a -> Proxy b -> ()
> proxyInEq _ _ = ()
>
> proxyInEq1 :: Proxy a -> Proxy (a+1) -> ()
> proxyInEq1 = proxyInEq
> ```
>
>
>
> degraded quite badly in terms of the error message.
>
> Where in GHC 9.0.1 we get:
>
>
>
> ```
>
> TestInEq.hs:11:14: error:
>     • Couldn't match type ‘a <=? (a + 1)’ with ‘'True’
>         arising from a use of ‘proxyInEq’
>     • In the expression: proxyInEq
>       In an equation for ‘proxyInEq1’: proxyInEq1 = proxyInEq
>     • Relevant bindings include
>         proxyInEq1 :: Proxy a -> Proxy (a + 1) -> ()
>           (bound at TestInEq.hs:11:1)
>    |
> 11 | proxyInEq1 = proxyInEq
>    |
>
> ```
>
>
>
> with GHC 9.2.0.20210422 we get:
>
>
>
> ```
>
> TestInEq.hs:11:14: error:
>     • Couldn't match type ‘Data.Type.Ord.OrdCond
>                              (CmpNat a (a + 1)) 'True 'True 'False’
>                      with ‘'True’
>         arising from a use of ‘proxyInEq’
>     • In the expression: proxyInEq
>       In an equation for ‘proxyInEq1’: proxyInEq1 = proxyInEq
>     • Relevant bindings include
>         proxyInEq1 :: Proxy a -> Proxy (a + 1) -> ()
>           (bound at TestInEq.hs:11:1)
>    |
> 11 | proxyInEq1 = proxyInEq
>    |
> ```
>
>
>
> Errors messages involving type-level naturals and their operations already
> weren't the poster-child of comprehensable GHC error messages, but this
> change has made the situation worse in my opinion.
>
>
>
> This change in error message is due to:
> https://gitlab.haskell.org/ghc/ghc/-/commit/eea96042f1e8682605ae68db10f2bcdd7dab923e
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fcommit%2Feea96042f1e8682605ae68db10f2bcdd7dab923e&data=04%7C01%7Csimonpj%40microsoft.com%7C42380a30e7f54d6ad06708d931747622%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637595199077636846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=FfAQaEksSYEWNjOzuOmwhPXz6lI%2F5o5LT%2Ftwbh42wFM%3D&reserved=0>
>
>
>
> Is there a way we can get the nicer pre-9.2.0.2021 error message again
> before the proper 9.2.1 release?
>
> e.g. by doing one of the following:
>
> 1. Reinstate `(<=? :: Nat -> Nat -> Bool)` as a builtin type family
>
> 2. Somehow add a custom type-error to `Data.Type.Ord.OrdCond`
>
> 3. Don't expand type aliases in type errors
>
>
>
> What do you think? should this be fixed? should this be fixed before the
> 9.2.1 release?
>
>
>
> -- Christiaan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210617/b0fa11f0/attachment.html>

From ben at well-typed.com  Thu Jun 17 21:16:48 2021
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 17 Jun 2021 17:16:48 -0400
Subject: CI Status Update
In-Reply-To: <87czsnz5ey.fsf@smart-cactus.org>
References: <87czsnz5ey.fsf@smart-cactus.org>
Message-ID: <87a6noyyx3.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Hi all,
>
Hi all,

At this point CI should be fully functional on the stable and master
branches again. However, do note that older base commits may refer to
Docker images that are sadly no longer available. Such cases can be
resolved by simply rebasing.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210617/6292454a/attachment.sig>

From john.ericson at obsidian.systems  Fri Jun 18 15:55:49 2021
From: john.ericson at obsidian.systems (John Ericson)
Date: Fri, 18 Jun 2021 11:55:49 -0400
Subject: Is simplified subsumption really necessary?
In-Reply-To: <AM5PR83MB03535D5EF2252800C1C66143AD0F9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <CAPq5Pv+CNBxA42shWao6Z+MQ4xXiWwi96Gb1eW_TxQRqiDd9rw@mail.gmail.com>
 <AM5PR83MB03535D5EF2252800C1C66143AD0F9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <40fcef62-e173-780d-5a5d-dd2d198647b3@obsidian.systems>

On 6/16/21 12:00 PM, Simon Peyton Jones via ghc-devs wrote:

> I’m sorry to hear that Chris. It’s exactly backwards from what I would 
> expect – the typing rules with simple subsumption are, well, simpler 
> than those for complicated subsumption, and so one might hope that 
> your intuition had fewer complexities to grapple with.
>
In https://richarde.dev/papers/2021/stability/stability.pdf it is written

    The analysis around stability in this paper strongly suggests that
    GHC should use the lazy, shallow approach to instantiation. Yet the
    struggles with lazy instantiation above remain. In order to simplify
    the implementation, GHC has recently (for GHC 9.0) switched to use
    exclusively eager instantiation.This choice sacrifices stability for
    convenience in implementation.

I think the principles outlined in the paper are very good, and explain 
the queasiness some users may feel in 9.0

> But wouldn't it be possible to choose a desugaring with seq that 
> doesn't do so?
>
> I just don’t know how to do that.  Maybe someone else does.
>
Is it not

   f `seq` \x -> f x

and similar? I haven't thought about the issue in a while or in very 
much depth, but when I first discussed the proposal years back with some 
other people at work, they spit-balled the same counter-proposal.

----

Having little "skin in the game" as I haven't yet ported any serious 
programs over to 9.0, I suppose I am glad the experimentation with 
QuickLook is happening, and OK that our accepting on-par fewer programs 
now opens design space for later (i.e. we got the breakage out of the 
way.) But I certainly think there are improvements in the spirit 
outlined in Richard's paper to be done down the road.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210618/7acd0226/attachment.html>

From simonpj at microsoft.com  Fri Jun 18 19:56:50 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 18 Jun 2021 19:56:50 +0000
Subject: Is simplified subsumption really necessary?
In-Reply-To: <40fcef62-e173-780d-5a5d-dd2d198647b3@obsidian.systems>
References: <CAPq5Pv+CNBxA42shWao6Z+MQ4xXiWwi96Gb1eW_TxQRqiDd9rw@mail.gmail.com>
 <AM5PR83MB03535D5EF2252800C1C66143AD0F9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <40fcef62-e173-780d-5a5d-dd2d198647b3@obsidian.systems>
Message-ID: <HE1PR83MB0361FE9727C4D04C88115B4CAD0D9@HE1PR83MB0361.EURPRD83.prod.outlook.com>

Richard's paper argues for lazy rather than eager instantiation.

It does not argue for deep rather than shallow subsumption and instantiation; on the contrary, it argues for shallow.  (That is, for "simple subsumption".)   And it is simple subsumption that is the focus of this conversation.

Simon

From: John Ericson <john.ericson at obsidian.systems>
Sent: 18 June 2021 16:56
To: ghc-devs <ghc-devs at haskell.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com>
Subject: Re: Is simplified subsumption really necessary?


On 6/16/21 12:00 PM, Simon Peyton Jones via ghc-devs wrote:
 I'm sorry to hear that Chris.   It's exactly backwards from what I would expect - the typing rules with simple subsumption are, well, simpler than those for complicated subsumption, and so one might hope that your intuition had fewer complexities to grapple with.

In https://richarde.dev/papers/2021/stability/stability.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fricharde.dev%2Fpapers%2F2021%2Fstability%2Fstability.pdf&data=04%7C01%7Csimonpj%40microsoft.com%7C7655b09d06a54a4af03508d9327193cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637596286139778988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=R1quXKjsnEjusvX%2BSxhPT25t%2B%2Bwqwo7mTPhnulvctQ0%3D&reserved=0> it is written

The analysis around stability in this paper strongly suggests that GHC should use the lazy, shallow approach to instantiation. Yet the struggles with lazy instantiation above remain. In order to simplify the implementation, GHC has recently (for GHC 9.0) switched to use exclusively eager instantiation.This choice sacrifices stability for convenience in implementation.

I think the principles outlined in the paper are very good, and explain the queasiness some users may feel in 9.0

But wouldn't it be possible to choose a desugaring with seq that doesn't do so?

I just don't know how to do that.  Maybe someone else does.

Is it not

  f `seq` \x -> f x

and similar? I haven't thought about the issue in a while or in very much depth, but when I first discussed the proposal years back with some other people at work, they spit-balled the same counter-proposal.

----

Having little "skin in the game" as I haven't yet ported any serious programs over to 9.0, I suppose I am glad the experimentation with QuickLook is happening, and OK that our accepting on-par fewer programs now opens design space for later (i.e. we got the breakage out of the way.) But I certainly think there are improvements in the spirit outlined in Richard's paper to be done down the road.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210618/2111b6cd/attachment.html>

From harendra.kumar at gmail.com  Sun Jun 20 06:51:33 2021
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Sun, 20 Jun 2021 12:21:33 +0530
Subject: Breaking changes to the base library
Message-ID: <CAPW+kkZiYC0-FcD7meOwbxD1q6y=Rt_gi7pqU3mjhiKkrnHc8g@mail.gmail.com>

I see the following errors when compiling with ghc head version:

$ ghc-stage2 --version
The Glorious Glasgow Haskell Compilation System, version 9.3.20210608

$ cabal build --with-compiler ghc-stage2 --allow-newer

Data/Colour/CIE.hs:80:12: error:
    Ambiguous occurrence ‘sum’
    It could refer to
       either ‘Prelude.sum’,
              imported from ‘Prelude’ at Data/Colour/CIE.hs:25:8-22
              (and originally defined in ‘Data.Foldable’)
           or ‘Data.List.sum’,
              imported from ‘Data.List’ at Data/Colour/CIE.hs:41:1-16
              (and originally defined in ‘GHC.List’)
   |
80 |    total = sum $ map fst l
   |            ^^^

Can someone briefly describe this change and what's the recommended way of
fixing this? Just hide the Data.List definition? I do not see this
mentioned in the release notes of 9.2/9.4 here:
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/9.2.1-notes.html

-harendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210620/62f1bfc6/attachment.html>

From ben at smart-cactus.org  Sun Jun 20 11:43:07 2021
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 20 Jun 2021 07:43:07 -0400
Subject: Breaking changes to the base library
In-Reply-To: <CAPW+kkZiYC0-FcD7meOwbxD1q6y=Rt_gi7pqU3mjhiKkrnHc8g@mail.gmail.com>
References: <CAPW+kkZiYC0-FcD7meOwbxD1q6y=Rt_gi7pqU3mjhiKkrnHc8g@mail.gmail.com>
Message-ID: <87zgvkyd6e.fsf@smart-cactus.org>

Harendra Kumar <harendra.kumar at gmail.com> writes:

> I see the following errors when compiling with ghc head version:
>
> $ ghc-stage2 --version
> The Glorious Glasgow Haskell Compilation System, version 9.3.20210608
>
> $ cabal build --with-compiler ghc-stage2 --allow-newer
>
> Data/Colour/CIE.hs:80:12: error:
>     Ambiguous occurrence ‘sum’
>     It could refer to
>        either ‘Prelude.sum’,
>               imported from ‘Prelude’ at Data/Colour/CIE.hs:25:8-22
>               (and originally defined in ‘Data.Foldable’)
>            or ‘Data.List.sum’,
>               imported from ‘Data.List’ at Data/Colour/CIE.hs:41:1-16
>               (and originally defined in ‘GHC.List’)
>    |
> 80 |    total = sum $ map fst l
>    |            ^^^
>
> Can someone briefly describe this change and what's the recommended way of
> fixing this? Just hide the Data.List definition? I do not see this
> mentioned in the release notes of 9.2/9.4 here:
> https://ghc.gitlab.haskell.org/ghc/doc/users_guide/9.2.1-notes.html
>
Indeed, this is due to the monomorphic Data.List proposal, which the
CLC decided would accompany the addition of Data.List.singleton. The
correct fix here is to either qualify the import of `Data.List` or add
an explicit import list. I'll try to remember to add a note about this
to the release notes and migration guide.


Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210620/24803ab2/attachment.sig>

From cdsmith at gmail.com  Sun Jun 20 11:44:34 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Sun, 20 Jun 2021 07:44:34 -0400
Subject: Breaking changes to the base library
In-Reply-To: <87zgvkyd6e.fsf@smart-cactus.org>
References: <CAPW+kkZiYC0-FcD7meOwbxD1q6y=Rt_gi7pqU3mjhiKkrnHc8g@mail.gmail.com>
 <87zgvkyd6e.fsf@smart-cactus.org>
Message-ID: <CAPq5Pv+ZYSZ5LUzuTiGPXE10rmJ=7C0q8DkVAbyntERgOTzysA@mail.gmail.com>

Yikes, this is going to break nearly everything.  Definitely good to let
people know.

On Sun, Jun 20, 2021 at 7:43 AM Ben Gamari <ben at smart-cactus.org> wrote:

> Harendra Kumar <harendra.kumar at gmail.com> writes:
>
> > I see the following errors when compiling with ghc head version:
> >
> > $ ghc-stage2 --version
> > The Glorious Glasgow Haskell Compilation System, version 9.3.20210608
> >
> > $ cabal build --with-compiler ghc-stage2 --allow-newer
> >
> > Data/Colour/CIE.hs:80:12: error:
> >     Ambiguous occurrence ‘sum’
> >     It could refer to
> >        either ‘Prelude.sum’,
> >               imported from ‘Prelude’ at Data/Colour/CIE.hs:25:8-22
> >               (and originally defined in ‘Data.Foldable’)
> >            or ‘Data.List.sum’,
> >               imported from ‘Data.List’ at Data/Colour/CIE.hs:41:1-16
> >               (and originally defined in ‘GHC.List’)
> >    |
> > 80 |    total = sum $ map fst l
> >    |            ^^^
> >
> > Can someone briefly describe this change and what's the recommended way
> of
> > fixing this? Just hide the Data.List definition? I do not see this
> > mentioned in the release notes of 9.2/9.4 here:
> > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/9.2.1-notes.html
> >
> Indeed, this is due to the monomorphic Data.List proposal, which the
> CLC decided would accompany the addition of Data.List.singleton. The
> correct fix here is to either qualify the import of `Data.List` or add
> an explicit import list. I'll try to remember to add a note about this
> to the release notes and migration guide.
>
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210620/36d55e88/attachment.html>

From ekmett at gmail.com  Sun Jun 20 14:57:49 2021
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 20 Jun 2021 07:57:49 -0700
Subject: Breaking changes to the base library
In-Reply-To: <CAPq5Pv+ZYSZ5LUzuTiGPXE10rmJ=7C0q8DkVAbyntERgOTzysA@mail.gmail.com>
References: <CAPW+kkZiYC0-FcD7meOwbxD1q6y=Rt_gi7pqU3mjhiKkrnHc8g@mail.gmail.com>
 <87zgvkyd6e.fsf@smart-cactus.org>
 <CAPq5Pv+ZYSZ5LUzuTiGPXE10rmJ=7C0q8DkVAbyntERgOTzysA@mail.gmail.com>
Message-ID: <CAJumaK-2yR10qi8L-jp9Kz3KDv-HDeFsaTXOshXVjD3UGw1kLw@mail.gmail.com>

The breakage concern is why Data.List wound up in its limbo-like state of
re-exporting the Foldable-polymorphic combinators since 7.10 -- while
"weird", it was the only option that didn't have to choose between removing
the names from Data.List exports entirely and breaking unqualified imports
of Data.List.

With the monomorphized combinators in place, Data.List should be considered
a 'qualified' import like Data.Map. We definitely need to do more to
communicate that this is changing and how users should adjust their code to
suit. After all, by far the most common intended import from Data.List is
the humble 'sort', which doesn't conflict.

-Edward

On Sun, Jun 20, 2021 at 4:45 AM Chris Smith <cdsmith at gmail.com> wrote:

> Yikes, this is going to break nearly everything.  Definitely good to let
> people know.
>
> On Sun, Jun 20, 2021 at 7:43 AM Ben Gamari <ben at smart-cactus.org> wrote:
>
>> Harendra Kumar <harendra.kumar at gmail.com> writes:
>>
>> > I see the following errors when compiling with ghc head version:
>> >
>> > $ ghc-stage2 --version
>> > The Glorious Glasgow Haskell Compilation System, version 9.3.20210608
>> >
>> > $ cabal build --with-compiler ghc-stage2 --allow-newer
>> >
>> > Data/Colour/CIE.hs:80:12: error:
>> >     Ambiguous occurrence ‘sum’
>> >     It could refer to
>> >        either ‘Prelude.sum’,
>> >               imported from ‘Prelude’ at Data/Colour/CIE.hs:25:8-22
>> >               (and originally defined in ‘Data.Foldable’)
>> >            or ‘Data.List.sum’,
>> >               imported from ‘Data.List’ at Data/Colour/CIE.hs:41:1-16
>> >               (and originally defined in ‘GHC.List’)
>> >    |
>> > 80 |    total = sum $ map fst l
>> >    |            ^^^
>> >
>> > Can someone briefly describe this change and what's the recommended way
>> of
>> > fixing this? Just hide the Data.List definition? I do not see this
>> > mentioned in the release notes of 9.2/9.4 here:
>> > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/9.2.1-notes.html
>> >
>> Indeed, this is due to the monomorphic Data.List proposal, which the
>> CLC decided would accompany the addition of Data.List.singleton. The
>> correct fix here is to either qualify the import of `Data.List` or add
>> an explicit import list. I'll try to remember to add a note about this
>> to the release notes and migration guide.
>>
>>
>> Cheers,
>>
>> - Ben
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210620/864a974b/attachment.html>

From oleg.grenrus at iki.fi  Sun Jun 20 15:08:46 2021
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Sun, 20 Jun 2021 18:08:46 +0300
Subject: Breaking changes to the base library
In-Reply-To: <CAJumaK-2yR10qi8L-jp9Kz3KDv-HDeFsaTXOshXVjD3UGw1kLw@mail.gmail.com>
References: <CAPW+kkZiYC0-FcD7meOwbxD1q6y=Rt_gi7pqU3mjhiKkrnHc8g@mail.gmail.com>
 <87zgvkyd6e.fsf@smart-cactus.org>
 <CAPq5Pv+ZYSZ5LUzuTiGPXE10rmJ=7C0q8DkVAbyntERgOTzysA@mail.gmail.com>
 <CAJumaK-2yR10qi8L-jp9Kz3KDv-HDeFsaTXOshXVjD3UGw1kLw@mail.gmail.com>
Message-ID: <f6adbce6-d2bb-924a-3215-dde0857cda52@iki.fi>

What is the reason that -Wcompat flags are not enabled by -Wall? The
unqualified Data.List import was warned by -Wcompat about since
GHC-8.10, I'm surprised that it still surprise people.

Should -Wcompat be implied by -Wall? Why not? I think that people who
won't ever consider upgrading GHC to be a very very small minority, and
they can suppress these warnings with `-Wall -Wno-compat`.

- Oleg

On 20.6.2021 17.57, Edward Kmett wrote:
> The breakage concern is why Data.List wound up in its limbo-like state
> of re-exporting the Foldable-polymorphic combinators since 7.10 --
> while "weird", it was the only option that didn't have to choose
> between removing the names from Data.List exports entirely and
> breaking unqualified imports of Data.List.
>
> With the monomorphized combinators in place, Data.List should be
> considered a 'qualified' import like Data.Map. We definitely need to
> do more to communicate that this is changing and how users should
> adjust their code to suit. After all, by far the most common intended
> import from Data.List is the humble 'sort', which doesn't conflict.
>
> -Edward
>
> On Sun, Jun 20, 2021 at 4:45 AM Chris Smith <cdsmith at gmail.com
> <mailto:cdsmith at gmail.com>> wrote:
>
>     Yikes, this is going to break nearly everything.  Definitely good
>     to let people know.
>
>     On Sun, Jun 20, 2021 at 7:43 AM Ben Gamari <ben at smart-cactus.org
>     <mailto:ben at smart-cactus.org>> wrote:
>
>         Harendra Kumar <harendra.kumar at gmail.com
>         <mailto:harendra.kumar at gmail.com>> writes:
>
>         > I see the following errors when compiling with ghc head version:
>         >
>         > $ ghc-stage2 --version
>         > The Glorious Glasgow Haskell Compilation System, version
>         9.3.20210608
>         >
>         > $ cabal build --with-compiler ghc-stage2 --allow-newer
>         >
>         > Data/Colour/CIE.hs:80:12: error:
>         >     Ambiguous occurrence ‘sum’
>         >     It could refer to
>         >        either ‘Prelude.sum’,
>         >               imported from ‘Prelude’ at
>         Data/Colour/CIE.hs:25:8-22
>         >               (and originally defined in ‘Data.Foldable’)
>         >            or ‘Data.List.sum’,
>         >               imported from ‘Data.List’ at
>         Data/Colour/CIE.hs:41:1-16
>         >               (and originally defined in ‘GHC.List’)
>         >    |
>         > 80 |    total = sum $ map fst l
>         >    |            ^^^
>         >
>         > Can someone briefly describe this change and what's the
>         recommended way of
>         > fixing this? Just hide the Data.List definition? I do not
>         see this
>         > mentioned in the release notes of 9.2/9.4 here:
>         >
>         https://ghc.gitlab.haskell.org/ghc/doc/users_guide/9.2.1-notes.html
>         >
>         Indeed, this is due to the monomorphic Data.List proposal,
>         which the
>         CLC decided would accompany the addition of
>         Data.List.singleton. The
>         correct fix here is to either qualify the import of
>         `Data.List` or add
>         an explicit import list. I'll try to remember to add a note
>         about this
>         to the release notes and migration guide.
>
>
>         Cheers,
>
>         - Ben
>
>         _______________________________________________
>         ghc-devs mailing list
>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210620/11a61596/attachment.html>

From carter.schonwald at gmail.com  Sun Jun 20 15:42:57 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 20 Jun 2021 11:42:57 -0400
Subject: Breaking changes to the base library
In-Reply-To: <f6adbce6-d2bb-924a-3215-dde0857cda52@iki.fi>
References: <CAPW+kkZiYC0-FcD7meOwbxD1q6y=Rt_gi7pqU3mjhiKkrnHc8g@mail.gmail.com>
 <87zgvkyd6e.fsf@smart-cactus.org>
 <CAPq5Pv+ZYSZ5LUzuTiGPXE10rmJ=7C0q8DkVAbyntERgOTzysA@mail.gmail.com>
 <CAJumaK-2yR10qi8L-jp9Kz3KDv-HDeFsaTXOshXVjD3UGw1kLw@mail.gmail.com>
 <f6adbce6-d2bb-924a-3215-dde0857cda52@iki.fi>
Message-ID: <CAHYVw0wdJpFdHNmJ2q_SDoJ+x-b6trSNExKUZH10TP1iJ9fTDA@mail.gmail.com>

This is a good question / suggestion!

On Sun, Jun 20, 2021 at 11:09 AM Oleg Grenrus <oleg.grenrus at iki.fi> wrote:

> What is the reason that -Wcompat flags are not enabled by -Wall? The
> unqualified Data.List import was warned by -Wcompat about since GHC-8.10,
> I'm surprised that it still surprise people.
>
> Should -Wcompat be implied by -Wall? Why not? I think that people who
> won't ever consider upgrading GHC to be a very very small minority, and
> they can suppress these warnings with `-Wall -Wno-compat`.
>
>
> - Oleg
>
> On 20.6.2021 17.57, Edward Kmett wrote:
>
> The breakage concern is why Data.List wound up in its limbo-like state of
> re-exporting the Foldable-polymorphic combinators since 7.10 -- while
> "weird", it was the only option that didn't have to choose between removing
> the names from Data.List exports entirely and breaking unqualified imports
> of Data.List.
>
> With the monomorphized combinators in place, Data.List should be
> considered a 'qualified' import like Data.Map. We definitely need to do
> more to communicate that this is changing and how users should adjust their
> code to suit. After all, by far the most common intended import from
> Data.List is the humble 'sort', which doesn't conflict.
>
> -Edward
>
> On Sun, Jun 20, 2021 at 4:45 AM Chris Smith <cdsmith at gmail.com> wrote:
>
>> Yikes, this is going to break nearly everything.  Definitely good to let
>> people know.
>>
>> On Sun, Jun 20, 2021 at 7:43 AM Ben Gamari <ben at smart-cactus.org> wrote:
>>
>>> Harendra Kumar <harendra.kumar at gmail.com> writes:
>>>
>>> > I see the following errors when compiling with ghc head version:
>>> >
>>> > $ ghc-stage2 --version
>>> > The Glorious Glasgow Haskell Compilation System, version 9.3.20210608
>>> >
>>> > $ cabal build --with-compiler ghc-stage2 --allow-newer
>>> >
>>> > Data/Colour/CIE.hs:80:12: error:
>>> >     Ambiguous occurrence ‘sum’
>>> >     It could refer to
>>> >        either ‘Prelude.sum’,
>>> >               imported from ‘Prelude’ at Data/Colour/CIE.hs:25:8-22
>>> >               (and originally defined in ‘Data.Foldable’)
>>> >            or ‘Data.List.sum’,
>>> >               imported from ‘Data.List’ at Data/Colour/CIE.hs:41:1-16
>>> >               (and originally defined in ‘GHC.List’)
>>> >    |
>>> > 80 |    total = sum $ map fst l
>>> >    |            ^^^
>>> >
>>> > Can someone briefly describe this change and what's the recommended
>>> way of
>>> > fixing this? Just hide the Data.List definition? I do not see this
>>> > mentioned in the release notes of 9.2/9.4 here:
>>> > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/9.2.1-notes.html
>>> >
>>> Indeed, this is due to the monomorphic Data.List proposal, which the
>>> CLC decided would accompany the addition of Data.List.singleton. The
>>> correct fix here is to either qualify the import of `Data.List` or add
>>> an explicit import list. I'll try to remember to add a note about this
>>> to the release notes and migration guide.
>>>
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
> _______________________________________________
> ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210620/492473b4/attachment.html>

From john.ericson at obsidian.systems  Sun Jun 20 17:06:35 2021
From: john.ericson at obsidian.systems (John Ericson)
Date: Sun, 20 Jun 2021 13:06:35 -0400
Subject: Is simplified subsumption really necessary?
In-Reply-To: <HE1PR83MB0361FE9727C4D04C88115B4CAD0D9@HE1PR83MB0361.EURPRD83.prod.outlook.com>
References: <CAPq5Pv+CNBxA42shWao6Z+MQ4xXiWwi96Gb1eW_TxQRqiDd9rw@mail.gmail.com>
 <AM5PR83MB03535D5EF2252800C1C66143AD0F9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <40fcef62-e173-780d-5a5d-dd2d198647b3@obsidian.systems>
 <HE1PR83MB0361FE9727C4D04C88115B4CAD0D9@HE1PR83MB0361.EURPRD83.prod.outlook.com>
Message-ID: <7293a3b9-eb08-a52f-996e-118d61c67f87@obsidian.systems>

I'm sorry, I misunderstood the paper and thought the depth of the 
instantiation and subsumption could be varied more independently.

That said, what about the seq example below? Does forcing any function 
that is eta expanded like that sketchy to you? There is still a runtime 
cost to the eta expansion, but think with more elbow grease that could 
also be addressed (post-type-erasure optimization or new coercions).

John

On 6/18/21 3:56 PM, Simon Peyton Jones wrote:
>
> Richard’s paper argues for lazy rather than eager instantiation.
>
> It does *not* argue for deep rather than shallow subsumption and 
> instantiation; on the contrary, it argues for shallow.  (That is, for 
> “simple subsumption”.)   And it is simple subsumption that is the 
> focus of this conversation.
>
> Simon
>
> *From:*John Ericson <john.ericson at obsidian.systems>
> *Sent:* 18 June 2021 16:56
> *To:* ghc-devs <ghc-devs at haskell.org>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* Re: Is simplified subsumption really necessary?
>
> On 6/16/21 12:00 PM, Simon Peyton Jones via ghc-devs wrote:
>
>      I’m sorry to hear that Chris.   It’s exactly backwards from what
>     I would expect – the typing rules with simple subsumption are,
>     well, simpler than those for complicated subsumption, and so one
>     might hope that your intuition had fewer complexities to grapple
>     with.
>
> In https://richarde.dev/papers/2021/stability/stability.pdf 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fricharde.dev%2Fpapers%2F2021%2Fstability%2Fstability.pdf&data=04%7C01%7Csimonpj%40microsoft.com%7C7655b09d06a54a4af03508d9327193cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637596286139778988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=R1quXKjsnEjusvX%2BSxhPT25t%2B%2Bwqwo7mTPhnulvctQ0%3D&reserved=0> 
> it is written
>
>     The analysis around stability in this paper strongly suggests that
>     GHC should use the lazy, shallow approach to instantiation. Yet
>     the struggles with lazy instantiation above remain. In order to
>     simplify the implementation, GHC has recently (for GHC 9.0)
>     switched to use exclusively eager instantiation.This choice
>     sacrifices stability for convenience in implementation.
>
> I think the principles outlined in the paper are very good, and 
> explain the queasiness some users may feel in 9.0
>
>     But wouldn't it be possible to choose a desugaring with seq that
>     doesn't do so?
>
>     I just don’t know how to do that.  Maybe someone else does.
>
> Is it not
>
>   f `seq` \x -> f x
>
> and similar? I haven't thought about the issue in a while or in very 
> much depth, but when I first discussed the proposal years back with 
> some other people at work, they spit-balled the same counter-proposal.
>
> ----
>
> Having little "skin in the game" as I haven't yet ported any serious 
> programs over to 9.0, I suppose I am glad the experimentation with 
> QuickLook is happening, and OK that our accepting on-par fewer 
> programs now opens design space for later (i.e. we got the breakage 
> out of the way.) But I certainly think there are improvements in the 
> spirit outlined in Richard's paper to be done down the road.
>
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210620/f64b2fc0/attachment.html>

From harendra.kumar at gmail.com  Sun Jun 20 20:10:48 2021
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Mon, 21 Jun 2021 01:40:48 +0530
Subject: Breaking changes to the base library
In-Reply-To: <f6adbce6-d2bb-924a-3215-dde0857cda52@iki.fi>
References: <CAPW+kkZiYC0-FcD7meOwbxD1q6y=Rt_gi7pqU3mjhiKkrnHc8g@mail.gmail.com>
 <87zgvkyd6e.fsf@smart-cactus.org>
 <CAPq5Pv+ZYSZ5LUzuTiGPXE10rmJ=7C0q8DkVAbyntERgOTzysA@mail.gmail.com>
 <CAJumaK-2yR10qi8L-jp9Kz3KDv-HDeFsaTXOshXVjD3UGw1kLw@mail.gmail.com>
 <f6adbce6-d2bb-924a-3215-dde0857cda52@iki.fi>
Message-ID: <CAPW+kkZqS5jFuTMoK+kCeJktp6vpomqep=cubNZroKf0yAbtNA@mail.gmail.com>

Just an aside. I looked up the GHC user guide and found this:

-Wcompat-unqualified-imports

Warns on qualified imports of core library modules which are subject to
change in future GHC releases.
I got confused by the text. I guess it was meant to be "Warns on
unqualified imports".
-harendra

On Sun, 20 Jun 2021 at 20:39, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:

> What is the reason that -Wcompat flags are not enabled by -Wall? The
> unqualified Data.List import was warned by -Wcompat about since GHC-8.10,
> I'm surprised that it still surprise people.
>
> Should -Wcompat be implied by -Wall? Why not? I think that people who
> won't ever consider upgrading GHC to be a very very small minority, and
> they can suppress these warnings with `-Wall -Wno-compat`.
>
> - Oleg
>
> On 20.6.2021 17.57, Edward Kmett wrote:
>
> The breakage concern is why Data.List wound up in its limbo-like state of
> re-exporting the Foldable-polymorphic combinators since 7.10 -- while
> "weird", it was the only option that didn't have to choose between removing
> the names from Data.List exports entirely and breaking unqualified imports
> of Data.List.
>
> With the monomorphized combinators in place, Data.List should be
> considered a 'qualified' import like Data.Map. We definitely need to do
> more to communicate that this is changing and how users should adjust their
> code to suit. After all, by far the most common intended import from
> Data.List is the humble 'sort', which doesn't conflict.
>
> -Edward
>
> On Sun, Jun 20, 2021 at 4:45 AM Chris Smith <cdsmith at gmail.com> wrote:
>
>> Yikes, this is going to break nearly everything.  Definitely good to let
>> people know.
>>
>> On Sun, Jun 20, 2021 at 7:43 AM Ben Gamari <ben at smart-cactus.org> wrote:
>>
>>> Harendra Kumar <harendra.kumar at gmail.com> writes:
>>>
>>> > I see the following errors when compiling with ghc head version:
>>> >
>>> > $ ghc-stage2 --version
>>> > The Glorious Glasgow Haskell Compilation System, version 9.3.20210608
>>> >
>>> > $ cabal build --with-compiler ghc-stage2 --allow-newer
>>> >
>>> > Data/Colour/CIE.hs:80:12: error:
>>> >     Ambiguous occurrence ‘sum’
>>> >     It could refer to
>>> >        either ‘Prelude.sum’,
>>> >               imported from ‘Prelude’ at Data/Colour/CIE.hs:25:8-22
>>> >               (and originally defined in ‘Data.Foldable’)
>>> >            or ‘Data.List.sum’,
>>> >               imported from ‘Data.List’ at Data/Colour/CIE.hs:41:1-16
>>> >               (and originally defined in ‘GHC.List’)
>>> >    |
>>> > 80 |    total = sum $ map fst l
>>> >    |            ^^^
>>> >
>>> > Can someone briefly describe this change and what's the recommended
>>> way of
>>> > fixing this? Just hide the Data.List definition? I do not see this
>>> > mentioned in the release notes of 9.2/9.4 here:
>>> > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/9.2.1-notes.html
>>> >
>>> Indeed, this is due to the monomorphic Data.List proposal, which the
>>> CLC decided would accompany the addition of Data.List.singleton. The
>>> correct fix here is to either qualify the import of `Data.List` or add
>>> an explicit import list. I'll try to remember to add a note about this
>>> to the release notes and migration guide.
>>>
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
> _______________________________________________
> ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210621/05897849/attachment.html>

From simonpj at microsoft.com  Sun Jun 20 21:22:38 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sun, 20 Jun 2021 21:22:38 +0000
Subject: Is simplified subsumption really necessary?
In-Reply-To: <7293a3b9-eb08-a52f-996e-118d61c67f87@obsidian.systems>
References: <CAPq5Pv+CNBxA42shWao6Z+MQ4xXiWwi96Gb1eW_TxQRqiDd9rw@mail.gmail.com>
 <AM5PR83MB03535D5EF2252800C1C66143AD0F9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <40fcef62-e173-780d-5a5d-dd2d198647b3@obsidian.systems>
 <HE1PR83MB0361FE9727C4D04C88115B4CAD0D9@HE1PR83MB0361.EURPRD83.prod.outlook.com>
 <7293a3b9-eb08-a52f-996e-118d61c67f87@obsidian.systems>
Message-ID: <AM5PR83MB03534A61C2DFA42C0612E56FAD0B9@AM5PR83MB0353.EURPRD83.prod.outlook.com>

Yes, maybe the seq thing would be possible.   But it feels like a hack, and I'm far from convinced that the optimiser would really eliminate the overhead.    If I was convinced that deep subsumption was really better, it might be worth investigating the hack more deeply.   But in fact I've become convinced of the opposite, that deep subsumption just isn't worth the extra complexity - the simpler system allows Quick Look for example.

Simon

From: John Ericson <john.ericson at obsidian.systems>
Sent: 20 June 2021 18:07
To: ghc-devs <ghc-devs at haskell.org>; Simon Peyton Jones <simonpj at microsoft.com>
Subject: Re: Is simplified subsumption really necessary?


I'm sorry, I misunderstood the paper and thought the depth of the instantiation and subsumption could be varied more independently.

That said, what about the seq example below? Does forcing any function that is eta expanded like that sketchy to you? There is still a runtime cost to the eta expansion, but think with more elbow grease that could also be addressed (post-type-erasure optimization or new coercions).

John
On 6/18/21 3:56 PM, Simon Peyton Jones wrote:
Richard's paper argues for lazy rather than eager instantiation.

It does not argue for deep rather than shallow subsumption and instantiation; on the contrary, it argues for shallow.  (That is, for "simple subsumption".)   And it is simple subsumption that is the focus of this conversation.

Simon

From: John Ericson <john.ericson at obsidian.systems><mailto:john.ericson at obsidian.systems>
Sent: 18 June 2021 16:56
To: ghc-devs <ghc-devs at haskell.org><mailto:ghc-devs at haskell.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com><mailto:simonpj at microsoft.com>
Subject: Re: Is simplified subsumption really necessary?


On 6/16/21 12:00 PM, Simon Peyton Jones via ghc-devs wrote:
 I'm sorry to hear that Chris.   It's exactly backwards from what I would expect - the typing rules with simple subsumption are, well, simpler than those for complicated subsumption, and so one might hope that your intuition had fewer complexities to grapple with.

In https://richarde.dev/papers/2021/stability/stability.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fricharde.dev%2Fpapers%2F2021%2Fstability%2Fstability.pdf&data=04%7C01%7Csimonpj%40microsoft.com%7Cb9916cabe3744e44375008d9340dca51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637598056497592691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SqgQIEVpLIARanGOqvKDNOjG%2FtLFZ6v1XVXzCFD1FQE%3D&reserved=0> it is written

The analysis around stability in this paper strongly suggests that GHC should use the lazy, shallow approach to instantiation. Yet the struggles with lazy instantiation above remain. In order to simplify the implementation, GHC has recently (for GHC 9.0) switched to use exclusively eager instantiation.This choice sacrifices stability for convenience in implementation.

I think the principles outlined in the paper are very good, and explain the queasiness some users may feel in 9.0

But wouldn't it be possible to choose a desugaring with seq that doesn't do so?

I just don't know how to do that.  Maybe someone else does.

Is it not

  f `seq` \x -> f x

and similar? I haven't thought about the issue in a while or in very much depth, but when I first discussed the proposal years back with some other people at work, they spit-balled the same counter-proposal.

----

Having little "skin in the game" as I haven't yet ported any serious programs over to 9.0, I suppose I am glad the experimentation with QuickLook is happening, and OK that our accepting on-par fewer programs now opens design space for later (i.e. we got the breakage out of the way.) But I certainly think there are improvements in the spirit outlined in Richard's paper to be done down the road.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210620/285f8d21/attachment.html>

From simonpj at microsoft.com  Mon Jun 21 21:28:19 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 21 Jun 2021 21:28:19 +0000
Subject: An error occurred
Message-ID: <AM5PR83MB03535886321E97220256F2BAAD0A9@AM5PR83MB0353.EURPRD83.prod.outlook.com>

Ben
I'm getting this error "An error occurred while fetching the job log" a lot when trying to look at the result of CI.  It seems to come and go. Refreshing the browser generally does not fix it.  Coming back later sometimes does.
It's frustrating.  Do you have any idea what's happening or how I can avoid it?
Thanks
Simon

[cid:image001.png at 01D766EC.BBFC2D20]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210621/0ada7d9a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 120895 bytes
Desc: image001.png
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210621/0ada7d9a/attachment-0001.png>

From ben at well-typed.com  Tue Jun 22 00:14:42 2021
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 21 Jun 2021 20:14:42 -0400
Subject: An error occurred
In-Reply-To: <AM5PR83MB03535886321E97220256F2BAAD0A9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <AM5PR83MB03535886321E97220256F2BAAD0A9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <87r1guycul.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> Ben
> I'm getting this error "An error occurred while fetching the job log"
> a lot when trying to look at the result of CI. It seems to come and
> go. Refreshing the browser generally does not fix it. Coming back
> later sometimes does.
> It's frustrating.  Do you have any idea what's happening or how I can avoid it?

Hi Simon,

Yes, this is indeed quite unfortunate. This is due to the DreamHost
outage [1], which has now been on-going for more than a week now. Last
week I moved the Docker images away from DreamHost to get CI moving
again, but I didn't move the logs and build artifacts away under an
assumption that the issue would have been resolved by now.

At this point I think I'm going to move away from DreamHost entirely as
I have little confidence that this issue will be resolved in the near
future. I will do this tomorrow.

Cheers,

- Ben


From xnningxie at gmail.com  Wed Jun 23 18:27:50 2021
From: xnningxie at gmail.com (Ningning Xie)
Date: Wed, 23 Jun 2021 14:27:50 -0400
Subject: Final Call for Talks: Haskell Implementors' Workshop @ ICFP'21
Message-ID: <CABjRk3m5z2cZU4aPUuuCrJ9uzDk+UJaKa_JkpXjifGPHEmnTqA@mail.gmail.com>

                         Final Call for Talks
               ACM SIGPLAN Haskell Implementors' Workshop

                https://icfp21.sigplan.org/home/hiw-2021
                         Virtual, 22 Aug, 2021

                      Co-located with ICFP 2021
                     https://icfp21.sigplan.org/

New: Invited Speaker
--------------------

Title: Haskell reinterpreted – large-scale real-world experience with the Mu
compiler in Financial Markets
Speaker: Bengt Marten Agren, Standard Chartered Bank


Important dates
---------------

Deadline:       Wednesday, 30 June, 2021 (AoE)
Notification:   Wednesday, 14 July, 2021
Workshop:       Sunday, 22 August, 2021

The 13th Haskell Implementors' Workshop is to be held alongside ICFP
2021 this year virtually. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings. The workshop will be informal and interactive, with
open spaces in the timetable and room for ad-hoc discussion, demos,
and lightning short talks.

Scope and target audience
-------------------------

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2021. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides and presented data
available with the consent of the speakers.

The Implementors' Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related tool,
or even propose future lines of Haskell development. Members of the
wider Haskell community encouraged to attend the workshop -- we need
your feedback to keep the Haskell ecosystem thriving. Students working
with Haskell are specially encouraged to share their work.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

  * Compilation techniques
  * Language features and extensions
  * Type system implementation
  * Concurrency and parallelism: language design and implementation
  * Performance, optimisation and benchmarking
  * Virtual machines and run-time systems
  * Libraries and tools for development or deployment

Talks
-----

We invite proposals from potential speakers for talks and
demonstrations. We are aiming for 20-minute talks with 5 minutes for
questions and changeovers. We want to hear from people writing
compilers, tools, or libraries, people with cool ideas for directions in
which we should take the platform, proposals for new features to be
implemented, and half-baked crazy ideas. Please submit a talk title and
abstract of no more than 300 words.

Submissions should be made via HotCRP. The website is:
https://icfp-hiw21.hotcrp.com/

We will also have lightning talks session. These have been very well
received in recent years, and we aim to increase the time available to
them. Lightning talks be ~7mins and are scheduled on the day of the
workshop. Suggested topics for lightning talks are to present a single
idea, a work-in-progress project, a problem to intrigue and perplex
Haskell implementors, or simply to ask for feedback and collaborators.

Logistics
---------

Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW)
will be held remotely this year. However, the organizers are still
working hard to provide for a great workshop experience.

While we are sad that this year will lack the robust hallway track that
is often the highlight of HIW, we believe that this remote workshop
presents a unique opportunity to include more of the Haskell community
in our discussion and explore new modes of communicating with our
colleagues. We hope that you will join us in making this HIW as
vibrant as any other.


Program Committee
-----------------

  * Dominique Devriese (Vrije Universiteit Brussel)
  * Daan Leijen (Microsoft Research)
  * Andres Löh (Well-Typed LLP)
  * Julie Moronuki (Typeclass Consulting)
  * John Wiegley (DFINITY)
  * Ningning Xie (the University of Hong Kong)
  * Edward Z. Yang (Facebook AI Research)

Contact
-------

  * Ningning Xie <xnning at hku.hk>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210623/837dc9bd/attachment.html>

From christiaan.baaij at gmail.com  Thu Jun 24 09:56:16 2021
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Thu, 24 Jun 2021 11:56:16 +0200
Subject: Is there a way to prevent reboxing in W/W (due to OPAQUE pragma
 proposal)
Message-ID: <CABzw7bWiXiUfMR-z5f4qGzLiZGkqnagjQMRtfpD7o57km0i6tw@mail.gmail.com>

Hi Ghc-Devs,

I believe I've mostly finished the implementation of GHC proposal 0415 [1],
the OPAQUE pragma, over at:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5562

The only remaining issue is that I'm unsure whether there's a way to
prevent reboxing of worker arguments as witnessed here:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5562/diffs#29ad02619a9f318d67c6cd19648917dbb17354e9_0_134

Note that the reboxing doesn't happen in the worker of the OPAQUE-annotated
bindings, because OPAQUE-annotated bindings aren't W/W-transformed, but in
a worker of a function that calls the OPAQUE-annotated binding.
This reboxing was the reason behind the descision to W/W transform
NOINLINE-annotated bindings in:
https://gitlab.haskell.org/ghc/ghc/-/commit/b572aadb20c2e41e2f6d7b48401bd0b4239ce9f8

But the whole idea behind OPAQUE is not to change calls to the annotated
binding f by some call of a name-mangled version of f; so W/W transforming
OPAQUE-annoted binders is not an option.

Any hints on how to avoid the reboxing (if possible) would be appreciated,
like:
* Do I need to change something in GHC.Core.Opt.WorkWrap? or
* Do I need to change the demand/strictness signature of OPAQUE-annoted
bindings?
* or something else?

Thanks,

Christiaan

[1]
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0415-opaque-pragma.rst
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210624/f4cddd4e/attachment.html>

From simonpj at microsoft.com  Thu Jun 24 10:56:22 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 24 Jun 2021 10:56:22 +0000
Subject: Is there a way to prevent reboxing in W/W (due to OPAQUE pragma
 proposal)
In-Reply-To: <CABzw7bWiXiUfMR-z5f4qGzLiZGkqnagjQMRtfpD7o57km0i6tw@mail.gmail.com>
References: <CABzw7bWiXiUfMR-z5f4qGzLiZGkqnagjQMRtfpD7o57km0i6tw@mail.gmail.com>
Message-ID: <AM5PR83MB0353449E0765F9F380E03A95AD079@AM5PR83MB0353.EURPRD83.prod.outlook.com>

Christiaan

I'm totally paged out on this.  Would you like to do this via a comment on !5562, giving a concrete example of a small program that doesn't behave as you expect with your patch?

Sebastian may be able to help too.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Christiaan Baaij
Sent: 24 June 2021 10:56
To: ghc-devs <ghc-devs at haskell.org>
Subject: Is there a way to prevent reboxing in W/W (due to OPAQUE pragma proposal)

Hi Ghc-Devs,

I believe I've mostly finished the implementation of GHC proposal 0415 [1], the OPAQUE pragma, over at: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5562<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F5562&data=04%7C01%7Csimonpj%40microsoft.com%7C37d4e06b1380430d876f08d936f663b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637601254145010408%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9lJ%2FtKKqWsckKEofFLy3nZVq3RhRowOwEdWbI6RqNdY%3D&reserved=0>

The only remaining issue is that I'm unsure whether there's a way to prevent reboxing of worker arguments as witnessed here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5562/diffs#29ad02619a9f318d67c6cd19648917dbb17354e9_0_134<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F5562%2Fdiffs%2329ad02619a9f318d67c6cd19648917dbb17354e9_0_134&data=04%7C01%7Csimonpj%40microsoft.com%7C37d4e06b1380430d876f08d936f663b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637601254145020404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=O5MYMFoNW2xdhtE60AZBxwMTp1sRby1fvPkEpUHpak4%3D&reserved=0>

Note that the reboxing doesn't happen in the worker of the OPAQUE-annotated bindings, because OPAQUE-annotated bindings aren't W/W-transformed, but in a worker of a function that calls the OPAQUE-annotated binding.
This reboxing was the reason behind the descision to W/W transform NOINLINE-annotated bindings in: https://gitlab.haskell.org/ghc/ghc/-/commit/b572aadb20c2e41e2f6d7b48401bd0b4239ce9f8<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fcommit%2Fb572aadb20c2e41e2f6d7b48401bd0b4239ce9f8&data=04%7C01%7Csimonpj%40microsoft.com%7C37d4e06b1380430d876f08d936f663b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637601254145030396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3ysr8IzYCI925ZA9wh%2BL0wr3x516UZ4pFeSwuWsGv68%3D&reserved=0>

But the whole idea behind OPAQUE is not to change calls to the annotated binding f by some call of a name-mangled version of f; so W/W transforming OPAQUE-annoted binders is not an option.

Any hints on how to avoid the reboxing (if possible) would be appreciated, like:
* Do I need to change something in GHC.Core.Opt.WorkWrap? or
* Do I need to change the demand/strictness signature of OPAQUE-annoted bindings?
* or something else?

Thanks,

Christiaan

[1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0415-opaque-pragma.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0415-opaque-pragma.rst&data=04%7C01%7Csimonpj%40microsoft.com%7C37d4e06b1380430d876f08d936f663b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637601254145030396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kkmNa2MIWmrmpq6apCtD7bh8nxEFsdVZA8zuHe8vtPE%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210624/7489c8a7/attachment.html>

From sgraf1337 at gmail.com  Thu Jun 24 11:04:50 2021
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Thu, 24 Jun 2021 13:04:50 +0200
Subject: Is there a way to prevent reboxing in W/W (due to OPAQUE pragma
 proposal)
In-Reply-To: <CABzw7bWiXiUfMR-z5f4qGzLiZGkqnagjQMRtfpD7o57km0i6tw@mail.gmail.com>
References: <CABzw7bWiXiUfMR-z5f4qGzLiZGkqnagjQMRtfpD7o57km0i6tw@mail.gmail.com>
Message-ID: <CAAS+=P-VTZV1brJiEnaDFjBXYE7pW6mUhPwFhEWtXP73weZjug@mail.gmail.com>

Hi Christiaan,

Wow, the whole OPAQUE pragma proposal and implementation completely slipped
my attention.
I left a comment on the proposal about GHC.Exts.{lazy,noinline}.

Regarding the reboxing problem: You might want to wait for !5790
<https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5790>, which
represents boxity explicitly in the demand lattice, allowing you to get rid
of all boxity info in the demand signature of an OPAQUE function around the
call to `mkDmdTypeForArity`.
In the meantime, your best bet is to get rid of any strict product demands
in the demand signature, which at the moment says "unbox this thing,
because it is used unboxed".

Either way, you shouldn't even need to touch WW if you simply degrade the
(demand and CPR) signatures in that way, and it's more compositional, too,
because the analysis is able to propagate the "don't unbox" info to
callers, whereas it's too late to have non-local impact on callers of the
OPAQUE function when WW runs.

I enabled notifications for !5562, so feel free to continue the discussion
there.

Sebastian

Am Do., 24. Juni 2021 um 11:57 Uhr schrieb Christiaan Baaij <
christiaan.baaij at gmail.com>:

> Hi Ghc-Devs,
>
> I believe I've mostly finished the implementation of GHC proposal 0415
> [1], the OPAQUE pragma, over at:
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5562
>
> The only remaining issue is that I'm unsure whether there's a way to
> prevent reboxing of worker arguments as witnessed here:
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5562/diffs#29ad02619a9f318d67c6cd19648917dbb17354e9_0_134
>
> Note that the reboxing doesn't happen in the worker of the
> OPAQUE-annotated bindings, because OPAQUE-annotated bindings aren't
> W/W-transformed, but in a worker of a function that calls the
> OPAQUE-annotated binding.
> This reboxing was the reason behind the descision to W/W transform
> NOINLINE-annotated bindings in:
> https://gitlab.haskell.org/ghc/ghc/-/commit/b572aadb20c2e41e2f6d7b48401bd0b4239ce9f8
>
> But the whole idea behind OPAQUE is not to change calls to the annotated
> binding f by some call of a name-mangled version of f; so W/W transforming
> OPAQUE-annoted binders is not an option.
>
> Any hints on how to avoid the reboxing (if possible) would be appreciated,
> like:
> * Do I need to change something in GHC.Core.Opt.WorkWrap? or
> * Do I need to change the demand/strictness signature of OPAQUE-annoted
> bindings?
> * or something else?
>
> Thanks,
>
> Christiaan
>
> [1]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0415-opaque-pragma.rst
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210624/27ca4583/attachment.html>

From Gergo.Erdi at sc.com  Fri Jun 25 09:17:52 2021
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Fri, 25 Jun 2021 09:17:52 +0000
Subject: Loading a typechecked module and then using it immediately as a
 package
Message-ID: <HK0PR03MB4867143C018928AE9FE37A8FE9069@HK0PR03MB4867.apcprd03.prod.outlook.com>

PUBLIC

Hi,

I have the following to .hs files:


  1.  MyLib.hs:

module MyLib where
...

  2.  Test.hs:

{-# LANGUAGE PackageImports  #-}
module Test where
import "my-pkg" MyLib
...

I would like to parse/typecheck/load MyLib.hs into some Unit "my-unit", then add that to the package "my-pkg", and then typecheck Test.hs, all in-proc using the GHC API, without putting any other files on disk. How do I do that?

What I tried is loading MyLib.hs after setting the homeUnitId in the DynFlags to "my-unit", then editing the packageNameMap in the unitState of the DynFlags to may "my-pkg" to "my-unit":

setHomeUnit :: (GhcMonad m) => UnitId -> m ()
setHomeUnit unitId = do
    dflags <- getSessionDynFlags
    modifySession $ \h -> h{ hsc_dflags = dflags{ homeUnitId = unitId } }

registerUnit :: (GhcMonad m) => PackageName -> UnitId -> m ()
registerUnit pkg unitId = modifySession $ \h -> h{ hsc_dflags = addUnit $ hsc_dflags h }
  where
    addUnit dflags = dflags
        { unitState = let us = unitState dflags in us
            { packageNameMap = M.insert pkg (Indefinite unitId Nothing) $ packageNameMap us
            }
        }

pipeline = do
        setHomeUnit myUnit
        loadModule =<< typecheckModule =<< parseModule =<< modSumarryFor "MyLib"
        registerUnit myPkg myUnit

        setHomeUnit mainUnitId
        typecheckModule =<< parseModule =<< modSumarryFor "Test"


Alas, this doesn't work: the import of `MyLib` from `my-pkg` fails with:

input/linking/Test.hs:5:1: error:
    Could not find module 'MyLib'
    It is not a module in the current program, or in any known package.

TBH I'm not very surprised that it didn't work - that registerUnit function is doing some pretty deep surgery on the unitState that probably breaks several invariants. Still, I wasn't able to find a better way - all the functions in GHC.Unit.State seem to be for querying only.

Thanks,
            Gergo

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. 

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.

Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210625/26419f31/attachment.html>

From matthewtpickering at gmail.com  Fri Jun 25 10:54:18 2021
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 25 Jun 2021 11:54:18 +0100
Subject: Loading a typechecked module and then using it immediately as a
 package
In-Reply-To: <HK0PR03MB4867143C018928AE9FE37A8FE9069@HK0PR03MB4867.apcprd03.prod.outlook.com>
References: <HK0PR03MB4867143C018928AE9FE37A8FE9069@HK0PR03MB4867.apcprd03.prod.outlook.com>
Message-ID: <CALuQ0m-O4fOAdg+XMLn05q9Dt3ZG+cO5_m7d5P8YmoD4XArdDg@mail.gmail.com>

Hi Gergo,

Please see a minimal example in this gist.

https://gist.github.com/mpickering/5029c7f244c484c91d665bcbc6bc6406

Cheers,

Matt

On Fri, Jun 25, 2021 at 10:20 AM Erdi, Gergo via ghc-devs
<ghc-devs at haskell.org> wrote:
>
> PUBLIC
>
>
> Hi,
>
>
>
> I have the following to .hs files:
>
>
>
> MyLib.hs:
>
> module MyLib where
> …
>
> Test.hs:
>
> {-# LANGUAGE PackageImports  #-}
> module Test where
> import “my-pkg” MyLib
> …
>
>
>
> I would like to parse/typecheck/load MyLib.hs into some Unit “my-unit”, then add that to the package “my-pkg”, and then typecheck Test.hs, all in-proc using the GHC API, without putting any other files on disk. How do I do that?
>
>
>
> What I tried is loading MyLib.hs after setting the homeUnitId in the DynFlags to “my-unit”, then editing the packageNameMap in the unitState of the DynFlags to may “my-pkg” to “my-unit”:
>
> setHomeUnit :: (GhcMonad m) => UnitId -> m ()
>
> setHomeUnit unitId = do
>
>     dflags <- getSessionDynFlags
>
>     modifySession $ \h -> h{ hsc_dflags = dflags{ homeUnitId = unitId } }
>
>
>
> registerUnit :: (GhcMonad m) => PackageName -> UnitId -> m ()
>
> registerUnit pkg unitId = modifySession $ \h -> h{ hsc_dflags = addUnit $ hsc_dflags h }
>
>   where
>
>     addUnit dflags = dflags
>
>         { unitState = let us = unitState dflags in us
>
>             { packageNameMap = M.insert pkg (Indefinite unitId Nothing) $ packageNameMap us
>
>             }
>
>         }
>
>
>
> pipeline = do
>
>         setHomeUnit myUnit
>
>         loadModule =<< typecheckModule =<< parseModule =<< modSumarryFor “MyLib”
>
>         registerUnit myPkg myUnit
>
>
>
>         setHomeUnit mainUnitId
>
>         typecheckModule =<< parseModule =<< modSumarryFor “Test”
>
>
>
>
>
> Alas, this doesn’t work: the import of `MyLib` from `my-pkg` fails with:
>
>
>
> input/linking/Test.hs:5:1: error:
>
>     Could not find module ‘MyLib’
>
>     It is not a module in the current program, or in any known package.
>
>
>
> TBH I’m not very surprised that it didn’t work – that registerUnit function is doing some pretty deep surgery on the unitState that probably breaks several invariants. Still, I wasn’t able to find a better way – all the functions in GHC.Unit.State seem to be for querying only.
>
>
>
> Thanks,
>
>             Gergo
>
>
> This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From gergo at erdi.hu  Fri Jun 25 12:13:04 2021
From: gergo at erdi.hu (=?ISO-8859-2?Q?=C9RDI_Gerg=F5?=)
Date: Fri, 25 Jun 2021 20:13:04 +0800 (+08)
Subject: Loading a typechecked module and then using it immediately as
 a package
In-Reply-To: <CALuQ0m-O4fOAdg+XMLn05q9Dt3ZG+cO5_m7d5P8YmoD4XArdDg@mail.gmail.com>
References: <HK0PR03MB4867143C018928AE9FE37A8FE9069@HK0PR03MB4867.apcprd03.prod.outlook.com>
 <CALuQ0m-O4fOAdg+XMLn05q9Dt3ZG+cO5_m7d5P8YmoD4XArdDg@mail.gmail.com>
Message-ID: <alpine.DEB.2.22.394.2106252001410.279230@galaxy>

On Fri, 25 Jun 2021, Matthew Pickering wrote:

> Hi Gergo,
>
> Please see a minimal example in this gist.
>
> https://gist.github.com/mpickering/5029c7f244c484c91d665bcbc6bc6406

Thanks for the quick reply! Unfortunately, I won't be able to try it out 
until Monday.

From sam.derbyshire at gmail.com  Fri Jun 25 22:54:41 2021
From: sam.derbyshire at gmail.com (Sam Derbyshire)
Date: Sat, 26 Jun 2021 00:54:41 +0200
Subject: Rewriting plugins: request for feedback
In-Reply-To: <CABzw7bUqrkij=GT7P-yWqz=9Cph4jgLLnrMhSGcib7-g2P_OFg@mail.gmail.com>
References: <CAA1CnJPTysDy6mmD_hwCurvCP0k_+ORmxPeE0sR+1NWtbGKGkQ@mail.gmail.com>
 <CAA1CnJNQfcDj9CsQuPiVwyJ6=60uwY78Xc_9erRbvbCH51PeUQ@mail.gmail.com>
 <CAA1CnJPUA4vaW7X8FriJYn=he6VSG8p2j-GS=jVMzsy_=8hgjQ@mail.gmail.com>
 <CABzw7bUqrkij=GT7P-yWqz=9Cph4jgLLnrMhSGcib7-g2P_OFg@mail.gmail.com>
Message-ID: <CAA1CnJPzRMNN-PPk_4kWSSpH6-opZ-fXdo+Y1-f0yzSVQkX4eA@mail.gmail.com>

Hi everyone,

Just a short message to let authors of type-checking plugins know that I've
updated the ghc-tcplugin-api library with backwards compatibility for GHC
9.0 and 9.2.
The functionality for rewriting type family applications will obviously not
be present on those versions, but I hope this will allow plugin authors to
try out the API for themselves and see what they think.

It shouldn't be much different from what you are used to; mostly a change
from "TcPluginM a" to MTL-style "MonadTcPlugin m => m a", or explicit
solver monad  "TcPluginM Solve a".
The main improvements that this library offers in its current state are, in
my opinion, as follows:
  - Decoupling from GHC, which has several upsides:
    - needs of plugin authors can be addressed rapidly without needing to
wait for new GHC releases (of course, this doesn't apply to the changes
which require commensurate changes to GHC),
    - cross-compatibility across GHC versions, hopefully lightening the CPP
burden on plugin authors.
  - More extensive documentation that should help people get started with
typechecking plugins. The haddocks remain available at the same page:
https://sheaf.github.io/ghc-tcplugin-api/GHC-TcPlugin-API.html

The library is available on the GitHub repository as before:
https://github.com/sheaf/ghc-tcplugin-api
I will upload the library to Hackage soon.

Thanks all,

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210626/3d83cde0/attachment.html>

From Gergo.Erdi at sc.com  Mon Jun 28 06:41:18 2021
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Mon, 28 Jun 2021 06:41:18 +0000
Subject: [External] Re: Loading a typechecked module and then using it
 immediately as a package
In-Reply-To: <CALuQ0m-O4fOAdg+XMLn05q9Dt3ZG+cO5_m7d5P8YmoD4XArdDg@mail.gmail.com>
References: <HK0PR03MB4867143C018928AE9FE37A8FE9069@HK0PR03MB4867.apcprd03.prod.outlook.com>
 <CALuQ0m-O4fOAdg+XMLn05q9Dt3ZG+cO5_m7d5P8YmoD4XArdDg@mail.gmail.com>
Message-ID: <HK0PR03MB4867AB3246FA102B4E04F9E4E9039@HK0PR03MB4867.apcprd03.prod.outlook.com>

INTERNAL

Thanks, I got this working (after changing it slightly to use the GHC 9.0 API to the UnitState). However, I have some followup questions:

1. In the fakeUnitInfo, what is the relationship between unitLibraries and unitExposedModules? 
2. In the fakeUnitInfo, what is the unitImportDirs used for?
3. What is the difference between a PackageId and a PackageName?

Other than that, the code registers MyLib into the my-pkg package by letting `load` do the actual heavy lifting. For my purposes, I will need to control this loading myself: only `MyLib`'s typechecked interface should be used, with no actual compilation of definitions. So I wrote some code that makes a ModIface from a TcGblEnv. I seemingly got the whole thing working just by setting mi_exports from the TcGblEnv and leaving everything else with trivial values (fingerprint0 for fingerprints, empty lists for instances, etc.). If `MyLib` has no external dependencies and doesn't define any typeclasses, instances, or type families, is this enough? What is the role of `mi_globals`, should I set that from `tcg_rdr_env`, or should I leave it empty?

Thanks,
	Gergo


-----Original Message-----
From: Matthew Pickering <matthewtpickering at gmail.com> 
Sent: Friday, June 25, 2021 6:54 PM
To: Erdi, Gergo <Gergo.Erdi at sc.com>
Cc: ghc-devs at haskell.org
Subject: [External] Re: Loading a typechecked module and then using it immediately as a package

ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Always report suspicious emails using the Report As Phishing button in Outlook to protect the Bank and our clients.


Hi Gergo,

Please see a minimal example in this gist.

https://clicktime.symantec.com/3Eb2qXqu8Yp6VtdK9d5pNmL7Vc?u=https%3A%2F%2Fgist.github.com%2Fmpickering%2F5029c7f244c484c91d665bcbc6bc6406

Cheers,

Matt

On Fri, Jun 25, 2021 at 10:20 AM Erdi, Gergo via ghc-devs <ghc-devs at haskell.org> wrote:
>
> PUBLIC
>
>
> Hi,
>
>
>
> I have the following to .hs files:
>
>
>
> MyLib.hs:
>
> module MyLib where
> …
>
> Test.hs:
>
> {-# LANGUAGE PackageImports  #-}
> module Test where
> import “my-pkg” MyLib
> …
>
>
>
> I would like to parse/typecheck/load MyLib.hs into some Unit “my-unit”, then add that to the package “my-pkg”, and then typecheck Test.hs, all in-proc using the GHC API, without putting any other files on disk. How do I do that?
>
>
>
> What I tried is loading MyLib.hs after setting the homeUnitId in the DynFlags to “my-unit”, then editing the packageNameMap in the unitState of the DynFlags to may “my-pkg” to “my-unit”:
>
> setHomeUnit :: (GhcMonad m) => UnitId -> m ()
>
> setHomeUnit unitId = do
>
>     dflags <- getSessionDynFlags
>
>     modifySession $ \h -> h{ hsc_dflags = dflags{ homeUnitId = unitId 
> } }
>
>
>
> registerUnit :: (GhcMonad m) => PackageName -> UnitId -> m ()
>
> registerUnit pkg unitId = modifySession $ \h -> h{ hsc_dflags = 
> addUnit $ hsc_dflags h }
>
>   where
>
>     addUnit dflags = dflags
>
>         { unitState = let us = unitState dflags in us
>
>             { packageNameMap = M.insert pkg (Indefinite unitId 
> Nothing) $ packageNameMap us
>
>             }
>
>         }
>
>
>
> pipeline = do
>
>         setHomeUnit myUnit
>
>         loadModule =<< typecheckModule =<< parseModule =<< modSumarryFor “MyLib”
>
>         registerUnit myPkg myUnit
>
>
>
>         setHomeUnit mainUnitId
>
>         typecheckModule =<< parseModule =<< modSumarryFor “Test”
>
>
>
>
>
> Alas, this doesn’t work: the import of `MyLib` from `my-pkg` fails with:
>
>
>
> input/linking/Test.hs:5:1: error:
>
>     Could not find module ‘MyLib’
>
>     It is not a module in the current program, or in any known package.
>
>
>
> TBH I’m not very surprised that it didn’t work – that registerUnit function is doing some pretty deep surgery on the unitState that probably breaks several invariants. Still, I wasn’t able to find a better way – all the functions in GHC.Unit.State seem to be for querying only.
>
>
>
> Thanks,
>
>             Gergo
>
>
> This email and any attachments are confidential and may also be 
> privileged. If you are not the intended recipient, please delete all 
> copies and notify the sender immediately. You may wish to refer to the 
> incorporation details of Standard Chartered PLC, Standard Chartered 
> Bank and their subsidiaries at https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard 
> Chartered PLC, Standard Chartered Bank and their subsidiaries (the 
> "Group"), information on the regulatory standards we adhere to and how 
> it may affect you can be found in our Regulatory Compliance Statement 
> at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at 
> http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> https://clicktime.symantec.com/3A3FModesGCHWyu3Lvr5tp57Vc?u=http%3A%2F
> %2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. 

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.

Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

From Gergo.Erdi at sc.com  Mon Jun 28 07:03:38 2021
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Mon, 28 Jun 2021 07:03:38 +0000
Subject: [External] Re: Loading a typechecked module and then using it
 immediately as a package
In-Reply-To: <HK0PR03MB4867AB3246FA102B4E04F9E4E9039@HK0PR03MB4867.apcprd03.prod.outlook.com>
References: <HK0PR03MB4867143C018928AE9FE37A8FE9069@HK0PR03MB4867.apcprd03.prod.outlook.com>
 <CALuQ0m-O4fOAdg+XMLn05q9Dt3ZG+cO5_m7d5P8YmoD4XArdDg@mail.gmail.com>
 <HK0PR03MB4867AB3246FA102B4E04F9E4E9039@HK0PR03MB4867.apcprd03.prod.outlook.com>
Message-ID: <HK0PR03MB48679D36C238D26EF2C14FF2E9039@HK0PR03MB4867.apcprd03.prod.outlook.com>

INTERNAL

Oh, and one more question. This all works if in `Test.hs` I use a package import for `MyLib`. However, if I remove that, I get an error 

	attempting to use module ‘main:MyLib’ (input/MyLib.hs) which is not loaded

So I tried adding an ExposePackage to the DynFlags's packageFlags between loading the library and typechecking `Test.hs`, but I couldn't get that to work:
1. If I just set it in the `hsc_dflags`, it doesn't take.
2. If I use `initUnits` after setting it in `hsc_dflags`, I get a new error:

	cannot satisfy my-pkg


-----Original Message-----
From: Erdi, Gergo 
Sent: Monday, June 28, 2021 2:41 PM
To: Matthew Pickering <matthewtpickering at gmail.com>
Cc: ghc-devs at haskell.org
Subject: RE: [External] Re: Loading a typechecked module and then using it immediately as a package

INTERNAL

Thanks, I got this working (after changing it slightly to use the GHC 9.0 API to the UnitState). However, I have some followup questions:

1. In the fakeUnitInfo, what is the relationship between unitLibraries and unitExposedModules? 
2. In the fakeUnitInfo, what is the unitImportDirs used for?
3. What is the difference between a PackageId and a PackageName?

Other than that, the code registers MyLib into the my-pkg package by letting `load` do the actual heavy lifting. For my purposes, I will need to control this loading myself: only `MyLib`'s typechecked interface should be used, with no actual compilation of definitions. So I wrote some code that makes a ModIface from a TcGblEnv. I seemingly got the whole thing working just by setting mi_exports from the TcGblEnv and leaving everything else with trivial values (fingerprint0 for fingerprints, empty lists for instances, etc.). If `MyLib` has no external dependencies and doesn't define any typeclasses, instances, or type families, is this enough? What is the role of `mi_globals`, should I set that from `tcg_rdr_env`, or should I leave it empty?

Thanks,
	Gergo


-----Original Message-----
From: Matthew Pickering <matthewtpickering at gmail.com>
Sent: Friday, June 25, 2021 6:54 PM
To: Erdi, Gergo <Gergo.Erdi at sc.com>
Cc: ghc-devs at haskell.org
Subject: [External] Re: Loading a typechecked module and then using it immediately as a package

ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Always report suspicious emails using the Report As Phishing button in Outlook to protect the Bank and our clients.


Hi Gergo,

Please see a minimal example in this gist.

https://clicktime.symantec.com/3Eb2qXqu8Yp6VtdK9d5pNmL7Vc?u=https%3A%2F%2Fgist.github.com%2Fmpickering%2F5029c7f244c484c91d665bcbc6bc6406

Cheers,

Matt

On Fri, Jun 25, 2021 at 10:20 AM Erdi, Gergo via ghc-devs <ghc-devs at haskell.org> wrote:
>
> PUBLIC
>
>
> Hi,
>
>
>
> I have the following to .hs files:
>
>
>
> MyLib.hs:
>
> module MyLib where
> …
>
> Test.hs:
>
> {-# LANGUAGE PackageImports  #-}
> module Test where
> import “my-pkg” MyLib
> …
>
>
>
> I would like to parse/typecheck/load MyLib.hs into some Unit “my-unit”, then add that to the package “my-pkg”, and then typecheck Test.hs, all in-proc using the GHC API, without putting any other files on disk. How do I do that?
>
>
>
> What I tried is loading MyLib.hs after setting the homeUnitId in the DynFlags to “my-unit”, then editing the packageNameMap in the unitState of the DynFlags to may “my-pkg” to “my-unit”:
>
> setHomeUnit :: (GhcMonad m) => UnitId -> m ()
>
> setHomeUnit unitId = do
>
>     dflags <- getSessionDynFlags
>
>     modifySession $ \h -> h{ hsc_dflags = dflags{ homeUnitId = unitId 
> } }
>
>
>
> registerUnit :: (GhcMonad m) => PackageName -> UnitId -> m ()
>
> registerUnit pkg unitId = modifySession $ \h -> h{ hsc_dflags = 
> addUnit $ hsc_dflags h }
>
>   where
>
>     addUnit dflags = dflags
>
>         { unitState = let us = unitState dflags in us
>
>             { packageNameMap = M.insert pkg (Indefinite unitId
> Nothing) $ packageNameMap us
>
>             }
>
>         }
>
>
>
> pipeline = do
>
>         setHomeUnit myUnit
>
>         loadModule =<< typecheckModule =<< parseModule =<< modSumarryFor “MyLib”
>
>         registerUnit myPkg myUnit
>
>
>
>         setHomeUnit mainUnitId
>
>         typecheckModule =<< parseModule =<< modSumarryFor “Test”
>
>
>
>
>
> Alas, this doesn’t work: the import of `MyLib` from `my-pkg` fails with:
>
>
>
> input/linking/Test.hs:5:1: error:
>
>     Could not find module ‘MyLib’
>
>     It is not a module in the current program, or in any known package.
>
>
>
> TBH I’m not very surprised that it didn’t work – that registerUnit function is doing some pretty deep surgery on the unitState that probably breaks several invariants. Still, I wasn’t able to find a better way – all the functions in GHC.Unit.State seem to be for querying only.
>
>
>
> Thanks,
>
>             Gergo
>
>
> This email and any attachments are confidential and may also be 
> privileged. If you are not the intended recipient, please delete all 
> copies and notify the sender immediately. You may wish to refer to the 
> incorporation details of Standard Chartered PLC, Standard Chartered 
> Bank and their subsidiaries at https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard 
> Chartered PLC, Standard Chartered Bank and their subsidiaries (the 
> "Group"), information on the regulatory standards we adhere to and how 
> it may affect you can be found in our Regulatory Compliance Statement 
> at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at
> http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> https://clicktime.symantec.com/3A3FModesGCHWyu3Lvr5tp57Vc?u=http%3A%2F
> %2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. 

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.

Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

From Gergo.Erdi at sc.com  Tue Jun 29 08:40:32 2021
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Tue, 29 Jun 2021 08:40:32 +0000
Subject: Loading a typechecked module and then using it immediately as a
 package
Message-ID: <HK0PR03MB4867007F08E3702EF7052E50E9029@HK0PR03MB4867.apcprd03.prod.outlook.com>

PUBLIC

What's weird about it is that if I print the `moduleNameProvidersMap`, I can see `MyLib` inside, and it looks no different than any other module from e.g. `ghc-prim` that I can import into `Test.hs` without any package qualification. Also, why does the error message refer to the file name `input/MyLib.hs`? Why does GHC even know that that is where it would have to be loaded from, if it weren't to be used from an already loaded package?

-----Original Message-----
From: Erdi, Gergo 
Sent: Monday, June 28, 2021 3:04 PM
To: 'Matthew Pickering' <matthewtpickering at gmail.com>
Cc: 'ghc-devs at haskell.org' <ghc-devs at haskell.org>
Subject: RE: [External] Re: Loading a typechecked module and then using it immediately as a package

INTERNAL

Oh, and one more question. This all works if in `Test.hs` I use a package import for `MyLib`. However, if I remove that, I get an error 

	attempting to use module ‘main:MyLib’ (input/MyLib.hs) which is not loaded

So I tried adding an ExposePackage to the DynFlags's packageFlags between loading the library and typechecking `Test.hs`, but I couldn't get that to work:
1. If I just set it in the `hsc_dflags`, it doesn't take.
2. If I use `initUnits` after setting it in `hsc_dflags`, I get a new error:

	cannot satisfy my-pkg


-----Original Message-----
From: Erdi, Gergo
Sent: Monday, June 28, 2021 2:41 PM
To: Matthew Pickering <matthewtpickering at gmail.com>
Cc: ghc-devs at haskell.org
Subject: RE: [External] Re: Loading a typechecked module and then using it immediately as a package

INTERNAL

Thanks, I got this working (after changing it slightly to use the GHC 9.0 API to the UnitState). However, I have some followup questions:

1. In the fakeUnitInfo, what is the relationship between unitLibraries and unitExposedModules? 
2. In the fakeUnitInfo, what is the unitImportDirs used for?
3. What is the difference between a PackageId and a PackageName?

Other than that, the code registers MyLib into the my-pkg package by letting `load` do the actual heavy lifting. For my purposes, I will need to control this loading myself: only `MyLib`'s typechecked interface should be used, with no actual compilation of definitions. So I wrote some code that makes a ModIface from a TcGblEnv. I seemingly got the whole thing working just by setting mi_exports from the TcGblEnv and leaving everything else with trivial values (fingerprint0 for fingerprints, empty lists for instances, etc.). If `MyLib` has no external dependencies and doesn't define any typeclasses, instances, or type families, is this enough? What is the role of `mi_globals`, should I set that from `tcg_rdr_env`, or should I leave it empty?

Thanks,
	Gergo


-----Original Message-----
From: Matthew Pickering <matthewtpickering at gmail.com>
Sent: Friday, June 25, 2021 6:54 PM
To: Erdi, Gergo <Gergo.Erdi at sc.com>
Cc: ghc-devs at haskell.org
Subject: [External] Re: Loading a typechecked module and then using it immediately as a package

ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Always report suspicious emails using the Report As Phishing button in Outlook to protect the Bank and our clients.


Hi Gergo,

Please see a minimal example in this gist.

https://clicktime.symantec.com/3Eb2qXqu8Yp6VtdK9d5pNmL7Vc?u=https%3A%2F%2Fgist.github.com%2Fmpickering%2F5029c7f244c484c91d665bcbc6bc6406

Cheers,

Matt

On Fri, Jun 25, 2021 at 10:20 AM Erdi, Gergo via ghc-devs <ghc-devs at haskell.org> wrote:
>
> PUBLIC
>
>
> Hi,
>
>
>
> I have the following to .hs files:
>
>
>
> MyLib.hs:
>
> module MyLib where
> …
>
> Test.hs:
>
> {-# LANGUAGE PackageImports  #-}
> module Test where
> import “my-pkg” MyLib
> …
>
>
>
> I would like to parse/typecheck/load MyLib.hs into some Unit “my-unit”, then add that to the package “my-pkg”, and then typecheck Test.hs, all in-proc using the GHC API, without putting any other files on disk. How do I do that?
>
>
>
> What I tried is loading MyLib.hs after setting the homeUnitId in the DynFlags to “my-unit”, then editing the packageNameMap in the unitState of the DynFlags to may “my-pkg” to “my-unit”:
>
> setHomeUnit :: (GhcMonad m) => UnitId -> m ()
>
> setHomeUnit unitId = do
>
>     dflags <- getSessionDynFlags
>
>     modifySession $ \h -> h{ hsc_dflags = dflags{ homeUnitId = unitId 
> } }
>
>
>
> registerUnit :: (GhcMonad m) => PackageName -> UnitId -> m ()
>
> registerUnit pkg unitId = modifySession $ \h -> h{ hsc_dflags = 
> addUnit $ hsc_dflags h }
>
>   where
>
>     addUnit dflags = dflags
>
>         { unitState = let us = unitState dflags in us
>
>             { packageNameMap = M.insert pkg (Indefinite unitId
> Nothing) $ packageNameMap us
>
>             }
>
>         }
>
>
>
> pipeline = do
>
>         setHomeUnit myUnit
>
>         loadModule =<< typecheckModule =<< parseModule =<< modSumarryFor “MyLib”
>
>         registerUnit myPkg myUnit
>
>
>
>         setHomeUnit mainUnitId
>
>         typecheckModule =<< parseModule =<< modSumarryFor “Test”
>
>
>
>
>
> Alas, this doesn’t work: the import of `MyLib` from `my-pkg` fails with:
>
>
>
> input/linking/Test.hs:5:1: error:
>
>     Could not find module ‘MyLib’
>
>     It is not a module in the current program, or in any known package.
>
>
>
> TBH I’m not very surprised that it didn’t work – that registerUnit function is doing some pretty deep surgery on the unitState that probably breaks several invariants. Still, I wasn’t able to find a better way – all the functions in GHC.Unit.State seem to be for querying only.
>
>
>
> Thanks,
>
>             Gergo
>
>
> This email and any attachments are confidential and may also be 
> privileged. If you are not the intended recipient, please delete all 
> copies and notify the sender immediately. You may wish to refer to the 
> incorporation details of Standard Chartered PLC, Standard Chartered 
> Bank and their subsidiaries at https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard 
> Chartered PLC, Standard Chartered Bank and their subsidiaries (the 
> "Group"), information on the regulatory standards we adhere to and how 
> it may affect you can be found in our Regulatory Compliance Statement 
> at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at
> http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> https://clicktime.symantec.com/3A3FModesGCHWyu3Lvr5tp57Vc?u=http%3A%2F
> %2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. 

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.

Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

From Gergo.Erdi at sc.com  Tue Jun 29 10:13:58 2021
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Tue, 29 Jun 2021 10:13:58 +0000
Subject: Loading a typechecked module and then using it immediately as a
 package
In-Reply-To: <HK0PR03MB4867EE39498E353CA51DC014E9029@HK0PR03MB4867.apcprd03.prod.outlook.com>
References: <HK0PR03MB4867EE39498E353CA51DC014E9029@HK0PR03MB4867.apcprd03.prod.outlook.com>
Message-ID: <HK0PR03MB4867FC4B866EF176C074AEFCE9029@HK0PR03MB4867.apcprd03.prod.outlook.com>

PUBLIC

I don't know yet what's going on, but one thing I did notice is that `findInstalledHomeModule` returns `InstalledFound` for `MyLib`, which doesn't sound right to me -- `MyLib` should come from the "fake-uid" unit, and `Test` is typechecked in the `mainUnitId`.

-----Original Message-----
From: Erdi, Gergo 
Sent: Tuesday, June 29, 2021 5:51 PM
To: Matthew Pickering <matthewtpickering at gmail.com>
Subject: Re: Loading a typechecked module and then using it immediately as a package

PUBLIC

I tried moving `MyLib.hs` into a directory different than `Test.sh`, but the error message still refers to its correct location! So this error is not guessing the file name of where `MyLib.hs` could be loaded from; instead, it seems to refer correctly to where the module (previously loaded) was. Hmm.

-----Original Message-----
From: Matthew Pickering <matthewtpickering at gmail.com> 
Sent: Tuesday, June 29, 2021 5:04 PM
To: Erdi, Gergo <Gergo.Erdi at sc.com>
Subject: [External] Re: Loading a typechecked module and then using it immediately as a package


Do you have a `MyLib.hs` source file? If you move that somewhere else (another folder) then things might work?

On Tue, Jun 29, 2021 at 9:41 AM Erdi, Gergo <Gergo.Erdi at sc.com> wrote:
>
> PUBLIC
>
> What's weird about it is that if I print the `moduleNameProvidersMap`, I can see `MyLib` inside, and it looks no different than any other module from e.g. `ghc-prim` that I can import into `Test.hs` without any package qualification. Also, why does the error message refer to the file name `input/MyLib.hs`? Why does GHC even know that that is where it would have to be loaded from, if it weren't to be used from an already loaded package?
>

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. 

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.

Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

From matthewtpickering at gmail.com  Tue Jun 29 10:33:45 2021
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 29 Jun 2021 11:33:45 +0100
Subject: Loading a typechecked module and then using it immediately as a
 package
In-Reply-To: <HK0PR03MB4867FC4B866EF176C074AEFCE9029@HK0PR03MB4867.apcprd03.prod.outlook.com>
References: <HK0PR03MB4867EE39498E353CA51DC014E9029@HK0PR03MB4867.apcprd03.prod.outlook.com>
 <HK0PR03MB4867FC4B866EF176C074AEFCE9029@HK0PR03MB4867.apcprd03.prod.outlook.com>
Message-ID: <CALuQ0m-gM0Mf+GfVZ3t0Vd+ST9-s7tVOUK5UOV-PqzQ3kehuFA@mail.gmail.com>

Are you clearing the FinderCache?

On Tue, Jun 29, 2021 at 11:14 AM Erdi, Gergo <Gergo.Erdi at sc.com> wrote:
>
> PUBLIC
>
> I don't know yet what's going on, but one thing I did notice is that `findInstalledHomeModule` returns `InstalledFound` for `MyLib`, which doesn't sound right to me -- `MyLib` should come from the "fake-uid" unit, and `Test` is typechecked in the `mainUnitId`.
>
> -----Original Message-----
> From: Erdi, Gergo
> Sent: Tuesday, June 29, 2021 5:51 PM
> To: Matthew Pickering <matthewtpickering at gmail.com>
> Subject: Re: Loading a typechecked module and then using it immediately as a package
>
> PUBLIC
>
> I tried moving `MyLib.hs` into a directory different than `Test.sh`, but the error message still refers to its correct location! So this error is not guessing the file name of where `MyLib.hs` could be loaded from; instead, it seems to refer correctly to where the module (previously loaded) was. Hmm.
>
> -----Original Message-----
> From: Matthew Pickering <matthewtpickering at gmail.com>
> Sent: Tuesday, June 29, 2021 5:04 PM
> To: Erdi, Gergo <Gergo.Erdi at sc.com>
> Subject: [External] Re: Loading a typechecked module and then using it immediately as a package
>
>
> Do you have a `MyLib.hs` source file? If you move that somewhere else (another folder) then things might work?
>
> On Tue, Jun 29, 2021 at 9:41 AM Erdi, Gergo <Gergo.Erdi at sc.com> wrote:
> >
> > PUBLIC
> >
> > What's weird about it is that if I print the `moduleNameProvidersMap`, I can see `MyLib` inside, and it looks no different than any other module from e.g. `ghc-prim` that I can import into `Test.hs` without any package qualification. Also, why does the error message refer to the file name `input/MyLib.hs`? Why does GHC even know that that is where it would have to be loaded from, if it weren't to be used from an already loaded package?
> >
>
> This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

From Gergo.Erdi at sc.com  Tue Jun 29 10:59:59 2021
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Tue, 29 Jun 2021 10:59:59 +0000
Subject: Loading a typechecked module and then using it immediately as a
 package
Message-ID: <HK0PR03MB4867969944E202F4CB759EE1E9029@HK0PR03MB4867.apcprd03.prod.outlook.com>

PUBLIC

Should I? OK, I just tried calling `flushFinderCaches` after I change the home unit to `mainUnitId`, but I still get exactly the same behaviour: `findInstalledHomeModule` returns `InstalledFound` and things go downhill from there.

-----Original Message-----
From: Matthew Pickering <matthewtpickering at gmail.com> 
Sent: Tuesday, June 29, 2021 6:34 PM
To: Erdi, Gergo <Gergo.Erdi at sc.com>
Cc: ghc-devs at haskell.org
Subject: [External] Re: Loading a typechecked module and then using it immediately as a package

ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Always report suspicious emails using the Report As Phishing button in Outlook to protect the Bank and our clients.


Are you clearing the FinderCache?

On Tue, Jun 29, 2021 at 11:14 AM Erdi, Gergo <Gergo.Erdi at sc.com> wrote:
>
> PUBLIC
>
> I don't know yet what's going on, but one thing I did notice is that `findInstalledHomeModule` returns `InstalledFound` for `MyLib`, which doesn't sound right to me -- `MyLib` should come from the "fake-uid" unit, and `Test` is typechecked in the `mainUnitId`.
>
> -----Original Message-----
> From: Erdi, Gergo
> Sent: Tuesday, June 29, 2021 5:51 PM
> To: Matthew Pickering <matthewtpickering at gmail.com>
> Subject: Re: Loading a typechecked module and then using it immediately as a package
>
> PUBLIC
>
> I tried moving `MyLib.hs` into a directory different than `Test.sh`, but the error message still refers to its correct location! So this error is not guessing the file name of where `MyLib.hs` could be loaded from; instead, it seems to refer correctly to where the module (previously loaded) was. Hmm.
>
> -----Original Message-----
> From: Matthew Pickering <matthewtpickering at gmail.com>
> Sent: Tuesday, June 29, 2021 5:04 PM
> To: Erdi, Gergo <Gergo.Erdi at sc.com>
> Subject: [External] Re: Loading a typechecked module and then using it immediately as a package
>
>
> Do you have a `MyLib.hs` source file? If you move that somewhere else (another folder) then things might work?
>
> On Tue, Jun 29, 2021 at 9:41 AM Erdi, Gergo <Gergo.Erdi at sc.com> wrote:
> >
> > PUBLIC
> >
> > What's weird about it is that if I print the `moduleNameProvidersMap`, I can see `MyLib` inside, and it looks no different than any other module from e.g. `ghc-prim` that I can import into `Test.hs` without any package qualification. Also, why does the error message refer to the file name `input/MyLib.hs`? Why does GHC even know that that is where it would have to be loaded from, if it weren't to be used from an already loaded package?
> >
>
> This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. 

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.

Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

From sylvain at haskus.fr  Tue Jun 29 12:30:26 2021
From: sylvain at haskus.fr (Sylvain Henry)
Date: Tue, 29 Jun 2021 14:30:26 +0200
Subject: Loading a typechecked module and then using it immediately as a
 package
In-Reply-To: <HK0PR03MB4867143C018928AE9FE37A8FE9069@HK0PR03MB4867.apcprd03.prod.outlook.com>
References: <HK0PR03MB4867143C018928AE9FE37A8FE9069@HK0PR03MB4867.apcprd03.prod.outlook.com>
Message-ID: <47bfe31e-19cd-2ab6-1779-7fe3b420a8e0@haskus.fr>

Hi,

This part of the API is still awful and a bit in flux to make it less 
so. Modifying the UnitState directly isn't currently supported and seems 
difficult to do correctly (e.g. in your code snippet below you don't 
modify the moduleNameProvidersMap field), so it would probably be better 
to recreate the UnitState from scratch with mkUnitState/initUnitConfig.

You may also have a look to 
GHC.Driver.Backpack.{withBkpSession,buildUnit} in TcSession mode which 
registers virtual units for Backpack's .bkp files similarly to what you 
want to do. If you really don't want to use the filesystem at all, 
however, I think you will have to deal with moving MyLib from the HPT to 
the EPS and I don't know if it is easily feasible (Backpack resets these 
tables via withTempSession so that interface files are read from disk as 
usual instead iiuc).

Good luck :)
Sylvain


On 25/06/2021 11:17, Erdi, Gergo via ghc-devs wrote:
>
> PUBLIC
>
>
> Hi,
>
> I have the following to .hs files:
>
>  1. MyLib.hs:
>
>     module MyLib where
>     …
>
>  2. Test.hs:
>
>     {-# LANGUAGE PackageImports  #-}
>     module Test where
>     import “my-pkg” MyLib
>     …
>
> I would like to parse/typecheck/load MyLib.hs into some Unit 
> “my-unit”, then add that to the package “my-pkg”, and then typecheck 
> Test.hs, all in-proc using the GHC API, without putting any other 
> files on disk. How do I do that?
>
> What I tried is loading MyLib.hs after setting the homeUnitId in the 
> DynFlags to “my-unit”, then editing the packageNameMap in the 
> unitState of the DynFlags to may “my-pkg” to “my-unit”:
>
> setHomeUnit :: (GhcMonad m) => UnitId -> m ()
>
> setHomeUnit unitId = do
>
>     dflags <- getSessionDynFlags
>
> modifySession $ \h -> h{ hsc_dflags = dflags{ homeUnitId = unitId } }
>
> registerUnit :: (GhcMonad m) => PackageName -> UnitId -> m ()
>
> registerUnit pkg unitId = modifySession $ \h -> h{ hsc_dflags = 
> addUnit $ hsc_dflags h }
>
>   where
>
>     addUnit dflags = dflags
>
>         { unitState = let us = unitState dflags in us
>
>             { packageNameMap = M.insert pkg (Indefinite unitId 
> Nothing) $ packageNameMap us
>
>             }
>
>         }
>
> pipeline = do
>
> setHomeUnit myUnit
>
> loadModule =<< typecheckModule =<< parseModule =<< modSumarryFor “MyLib”
>
> registerUnit myPkg myUnit
>
> setHomeUnit mainUnitId
>
> typecheckModule =<< parseModule =<< modSumarryFor “Test”
>
> Alas, this doesn’t work: the import of `MyLib` from `my-pkg` fails with:
>
> input/linking/Test.hs:5:1: error:
>
>     Could not find module ‘MyLib’
>
>     It is not a module in the current program, or in any known package.
>
> TBH I’m not very surprised that it didn’t work – that registerUnit 
> function is doing some pretty deep surgery on the unitState that 
> probably breaks several invariants. Still, I wasn’t able to find a 
> better way – all the functions in GHC.Unit.State seem to be for 
> querying only.
>
> Thanks,
>
> Gergo
>
>
> This email and any attachments are confidential and may also be 
> privileged. If you are not the intended recipient, please delete all 
> copies and notify the sender immediately. You may wish to refer to the 
> incorporation details of Standard Chartered PLC, Standard Chartered 
> Bank and their subsidiaries at https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard 
> Chartered PLC, Standard Chartered Bank and their subsidiaries (the 
> "Group"), information on the regulatory standards we adhere to and how 
> it may affect you can be found in our Regulatory Compliance Statement 
> at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at 
> http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team 
> and contains any market commentary, the market commentary has been 
> prepared by the sales and/or trading desk of Standard Chartered Bank 
> or its affiliate. It is not and does not constitute research material, 
> independent research, recommendation or financial advice. Any market 
> commentary is for information purpose only and shall not be relied on 
> for any other purpose and is subject to the relevant disclaimers 
> available at https: 
> //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and 
> contains any research materials prepared by members of the team, the 
> research material is for information purpose only and shall not be 
> relied on for any other purpose, and is subject to the relevant 
> disclaimers available at https: 
> //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed 
> transaction, by responding affirmatively to this e-mail, you agree 
> that you have understood the terms and conditions in the attached term 
> sheet and evaluated the merits and risks of the transaction. We may at 
> times also request you to sign the term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ 
> for important information with respect to derivative products.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210629/b763ba82/attachment.html>