From shayne.fletcher.50 at gmail.com  Sun Nov  1 16:29:55 2020
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Sun, 1 Nov 2020 11:29:55 -0500
Subject: msys woes
In-Reply-To: <CABHktDXLktA-ax8f-vdPn=7yvoohfdcYBunYs3VJA=8vZVp6mw@mail.gmail.com>
References: <CAMsAzy9B2gHCBwXTuAhFm2u+okX2AWpKoR8G1JDur8-841D1PA@mail.gmail.com>
 <CABHktDU=+fB3fv3x9db=J67ayWR7UGejX5pZ1Cii6Q1k5ppHBg@mail.gmail.com>
 <CAMsAzy9XY0vG8iS41_uzWR6VRfjJCJhQxQLdAELrxMx2qE0vyg@mail.gmail.com>
 <CAMsAzy_2fq0Hp38qrgs6KFkjUJqu1cHPjW7TNB6-x2UytVN0tA@mail.gmail.com>
 <CABHktDVtU3iSG-V6gswzkf29U9ArisBey1UjmfoYnSug0rfFRg@mail.gmail.com>
 <CAMsAzy89NChk63jGq_vDH2SYo6RRRTXcQitr0s9bDTG8RcQseA@mail.gmail.com>
 <CAMsAzy_zXbLx9cedsFX9UJQeU+G4xp_9dJ633arOgQDEJ9eQGQ@mail.gmail.com>
 <CABHktDWokVzs7PfXB304bJ9B3khy9HEhiKMg1Qr7R8_59GNoHg@mail.gmail.com>
 <CABHktDXLktA-ax8f-vdPn=7yvoohfdcYBunYs3VJA=8vZVp6mw@mail.gmail.com>
Message-ID: <CAMsAzy8KV8jVKye4rXePntRL64YUMtR_oUFwrXLsSRL+Ep0O5Q@mail.gmail.com>

On Thu, Oct 8, 2020 at 1:18 PM Phyx <lonetiger at gmail.com> wrote:

> From the looks of it the repo.msys2.org system doesn't have enough space
> to restore all these old packages.
>
> So we'll have to handle it on our end. The easiest way to get your builds
> working again is by applying a patch with the fix to the source tree.
>
>
New problems in this space as of today. This time with
```bash

stack --stack-yaml stack.yaml --resolver nightly-2020-01-08   exec --
pacman -S autoconf automake-wrapper make patch python tar mintty
--noconfirm
```

which produces 404 errors
```

2020-11-01T16:02:47.2564782Z :: Retrieving packages...
2020-11-01T16:02:49.0237771Z error: failed retrieving file
'diffutils-3.6-1-x86_64.pkg.tar.xz' from repo.msys2.org : The
requested URL returned error: 404
2020-11-01T16:02:49.3752086Z error: failed retrieving file
'diffutils-3.6-1-x86_64.pkg.tar.xz' from downloads.sourceforge.net :
The requested URL returned error: 404
2020-11-01T16:02:49.8476086Z error: failed retrieving file
'diffutils-3.6-1-x86_64.pkg.tar.xz' from www2.futureware.at : The
requested URL returned error: 404
2020-11-01T16:02:49.8482030Z warning: failed to retrieve some files
2020-11-01T16:02:51.2288388Z error: failed retrieving file
'autoconf-2.69-3-any.pkg.tar.xz' from repo.msys2.org : The requested
URL returned error: 404
2020-11-01T16:02:51.3674499Z error: failed retrieving file
'autoconf-2.69-3-any.pkg.tar.xz' from downloads.sourceforge.net : The
requested URL returned error: 404
2020-11-01T16:02:51.4787091Z error: failed retrieving file
'autoconf-2.69-3-any.pkg.tar.xz' from www2.futureware.at : The
requested URL returned error: 404
2020-11-01T16:02:51.4791763Z warning: failed to retrieve some files
...
```

I've raised https://github.com/msys2/MSYS2-packages/issues/2225 with msys2.
-- 
Shayne Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201101/da87a5b5/attachment.html>

From rae at richarde.dev  Tue Nov  3 18:15:19 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 3 Nov 2020 18:15:19 +0000
Subject: Tomorrow: Simon PJ announces Haskell Foundation
Message-ID: <010f01758f520a5c-ffadd00c-9d88-417b-b99d-5c948136bc2b-000000@us-east-2.amazonses.com>

Tomorrow (Wednesday Nov 4) at 12:00 UTC, Simon PJ will announce the formation of the Haskell Foundation, an independent, non-profit organization dedicated to broadening Haskell adoption. This will be a part of Haskell eXchange, but this announcement will be free to attend, via YouTube. Much of the presentation will be time for Q&A; questions can be posed both within the Haskell eXchange HopIn platform and via comments on YouTube.

Attend at https://youtu.be/MEmRarBL9kw <https://youtu.be/MEmRarBL9kw>

Just to forestall any disappointment: I won't be answering any questions here until at least after the announcement -- but do please come and ask questions there and afterwards.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201103/6e980c11/attachment.html>

From shayne.fletcher.50 at gmail.com  Wed Nov  4 01:18:21 2020
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Tue, 3 Nov 2020 20:18:21 -0500
Subject: msys woes
In-Reply-To: <87tuu9m0pi.fsf@smart-cactus.org>
References: <CAMsAzy9B2gHCBwXTuAhFm2u+okX2AWpKoR8G1JDur8-841D1PA@mail.gmail.com>
 <CABHktDU=+fB3fv3x9db=J67ayWR7UGejX5pZ1Cii6Q1k5ppHBg@mail.gmail.com>
 <CAMsAzy9XY0vG8iS41_uzWR6VRfjJCJhQxQLdAELrxMx2qE0vyg@mail.gmail.com>
 <CAMsAzy_2fq0Hp38qrgs6KFkjUJqu1cHPjW7TNB6-x2UytVN0tA@mail.gmail.com>
 <CABHktDVtU3iSG-V6gswzkf29U9ArisBey1UjmfoYnSug0rfFRg@mail.gmail.com>
 <CAMsAzy89NChk63jGq_vDH2SYo6RRRTXcQitr0s9bDTG8RcQseA@mail.gmail.com>
 <CAMsAzy_zXbLx9cedsFX9UJQeU+G4xp_9dJ633arOgQDEJ9eQGQ@mail.gmail.com>
 <CABHktDWokVzs7PfXB304bJ9B3khy9HEhiKMg1Qr7R8_59GNoHg@mail.gmail.com>
 <CABHktDXLktA-ax8f-vdPn=7yvoohfdcYBunYs3VJA=8vZVp6mw@mail.gmail.com>
 <CAMsAzy8KV8jVKye4rXePntRL64YUMtR_oUFwrXLsSRL+Ep0O5Q@mail.gmail.com>
 <87tuu9m0pi.fsf@smart-cactus.org>
Message-ID: <CAMsAzy_kREN_veNjE-E-xV7amOf4nx1L6U2jXru0zy4JuP8-8A@mail.gmail.com>

On Sun, Nov 1, 2020 at 12:44 PM Ben Gamari <bgamari at gmail.com> wrote:

> Shayne Fletcher <shayne.fletcher.50 at gmail.com> writes:
>
> > On Thu, Oct 8, 2020 at 1:18 PM Phyx <lonetiger at gmail.com> wrote:
> >
> >> From the looks of it the repo.msys2.org system doesn't have enough
> space
> >> to restore all these old packages.
> >>
> >> So we'll have to handle it on our end. The easiest way to get your
> builds
> >> working again is by applying a patch with the fix to the source tree.
> >>
> >>
> > New problems in this space as of today. This time with
> > ```bash
> >
> > stack --stack-yaml stack.yaml --resolver nightly-2020-01-08   exec --
> > pacman -S autoconf automake-wrapper make patch python tar mintty
> > --noconfirm
> > ```
> >
> > which produces 404 errors
>
> Oh dear; thank you for raising this with upstream, Shayne! Let's hope
> there is action soon.
>
>
After looking into it a bit, I'm beginning to think that it is in fact on
us (stack as it happens) to upgrade our msys installer. I have a workaround
for now:
```
stack exec -- curl -O
http://repo.msys2.org/msys/x86_64/msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz
stack exec --  pacman -U msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz
--noconfirm
stack exec -- pacman -Syu autoconf automake-wrapper make patch python tar
mintty --noconfirm"
```

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

From shayne.fletcher.50 at gmail.com  Wed Nov  4 04:24:46 2020
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Tue, 3 Nov 2020 23:24:46 -0500
Subject: msys woes
In-Reply-To: <CAMsAzy_kREN_veNjE-E-xV7amOf4nx1L6U2jXru0zy4JuP8-8A@mail.gmail.com>
References: <CAMsAzy9B2gHCBwXTuAhFm2u+okX2AWpKoR8G1JDur8-841D1PA@mail.gmail.com>
 <CABHktDU=+fB3fv3x9db=J67ayWR7UGejX5pZ1Cii6Q1k5ppHBg@mail.gmail.com>
 <CAMsAzy9XY0vG8iS41_uzWR6VRfjJCJhQxQLdAELrxMx2qE0vyg@mail.gmail.com>
 <CAMsAzy_2fq0Hp38qrgs6KFkjUJqu1cHPjW7TNB6-x2UytVN0tA@mail.gmail.com>
 <CABHktDVtU3iSG-V6gswzkf29U9ArisBey1UjmfoYnSug0rfFRg@mail.gmail.com>
 <CAMsAzy89NChk63jGq_vDH2SYo6RRRTXcQitr0s9bDTG8RcQseA@mail.gmail.com>
 <CAMsAzy_zXbLx9cedsFX9UJQeU+G4xp_9dJ633arOgQDEJ9eQGQ@mail.gmail.com>
 <CABHktDWokVzs7PfXB304bJ9B3khy9HEhiKMg1Qr7R8_59GNoHg@mail.gmail.com>
 <CABHktDXLktA-ax8f-vdPn=7yvoohfdcYBunYs3VJA=8vZVp6mw@mail.gmail.com>
 <CAMsAzy8KV8jVKye4rXePntRL64YUMtR_oUFwrXLsSRL+Ep0O5Q@mail.gmail.com>
 <87tuu9m0pi.fsf@smart-cactus.org>
 <CAMsAzy_kREN_veNjE-E-xV7amOf4nx1L6U2jXru0zy4JuP8-8A@mail.gmail.com>
Message-ID: <CAMsAzy9x_doSmEYu-vjUK9d7oJUtA5FkTGpq7PnmWYpR1qBMuQ@mail.gmail.com>

On Tue, Nov 3, 2020 at 8:18 PM Shayne Fletcher <shayne.fletcher.50 at gmail.com>
wrote:

>
>
> On Sun, Nov 1, 2020 at 12:44 PM Ben Gamari <bgamari at gmail.com> wrote:
>
>> Shayne Fletcher <shayne.fletcher.50 at gmail.com> writes:
>>
>> > On Thu, Oct 8, 2020 at 1:18 PM Phyx <lonetiger at gmail.com> wrote:
>> >
>> >> From the looks of it the repo.msys2.org system doesn't have enough
>> space
>> >> to restore all these old packages.
>> >>
>> >> So we'll have to handle it on our end. The easiest way to get your
>> builds
>> >> working again is by applying a patch with the fix to the source tree.
>> >>
>> >>
>> > New problems in this space as of today. This time with
>> > ```bash
>> >
>> > stack --stack-yaml stack.yaml --resolver nightly-2020-01-08   exec --
>> > pacman -S autoconf automake-wrapper make patch python tar mintty
>> > --noconfirm
>> > ```
>> >
>> > which produces 404 errors
>>
>> Oh dear; thank you for raising this with upstream, Shayne! Let's hope
>> there is action soon.
>>
>>
>
An updated stack has been pushed. Thanks to this the issue is resolved!

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

From rae at richarde.dev  Wed Nov  4 14:00:39 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 4 Nov 2020 14:00:39 +0000
Subject: Announcing the Haskell Foundation
Message-ID: <010f0175938f3c13-4a2fb1a4-40bf-4d14-abbb-e7ec70fc7add-000000@us-east-2.amazonses.com>

I'm very pleased to announce the creation of the Haskell Foundation (HF), an independent, non-profit organisation dedicated to broadening Haskell adoption.

Website: https://haskell.foundation/ <https://haskell.foundation/>
Twitter: @haskellfound
Founding whitepaper: https://haskell.foundation/whitepaper/ <https://haskell.foundation/whitepaper/>
Simon Peyton Jones's announcement, with lots of Q&A: https://www.youtube.com/watch?v=MEmRarBL9kw <https://www.youtube.com/watch?v=MEmRarBL9kw>
The "official" ask-me-anything on Reddit: https://www.reddit.com/r/haskell/comments/jnwg7i/haskell_foundation_ama/ <https://www.reddit.com/r/haskell/comments/jnwg7i/haskell_foundation_ama/>
Mailing list for future HF announcements: https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-announce <https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-announce>
Mailing list for HF discussion / involvement: https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss <https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss>

Please join the conversation. We need your participation to realize the vision of the foundation as *our* foundation, not *their* foundation.

Looking forward to seeing where this all leads!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201104/ec4ca498/attachment.html>

From rae at richarde.dev  Fri Nov  6 20:02:15 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 6 Nov 2020 20:02:15 +0000
Subject: Status of #10071 (class method deprecations)
In-Reply-To: <CAATCwUk2rU_Fgc0ZBoBHTaqsTt8aNzV=h2wm6Z=U3GCSvHTceA@mail.gmail.com>
References: <CAATCwUk2rU_Fgc0ZBoBHTaqsTt8aNzV=h2wm6Z=U3GCSvHTceA@mail.gmail.com>
Message-ID: <010f01759f2701c9-f8b9b664-f13a-4ded-9854-3f14a6172b52-000000@us-east-2.amazonses.com>

My take (not authoritative) is that some good ideas were floated, but nothing was decided on. Given that we now have a proper process for deciding on new features, I think we should use it, and go via a proposal. Note that I've fixed the link in the original description to point to https://gitlab.haskell.org/ghc/ghc/-/wikis/design/deprecation-mechanisms/type-class-methods

Richard

> On Nov 6, 2020, at 1:22 AM, Fumiaki Kinoshita <fumiexcel at gmail.com> wrote:
> 
> I stumbled upon a case where I want to deprecate a class method in favour of another (https://github.com/fumieval/witherable/pull/68 <https://github.com/fumieval/witherable/pull/68>), which reminded me of some discussion around Monad-of-no-return proposal.
> 
> There seems to be an old ticket, but I'm not sure what the status is -- 
> is this approved and waiting for implementation, or something which needs to be resubmitted to ghc-proposals? 
> https://gitlab.haskell.org/ghc/ghc/-/issues/10071 <https://gitlab.haskell.org/ghc/ghc/-/issues/10071>
> _______________________________________________
> 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/20201106/5f5f9411/attachment.html>

From rae at richarde.dev  Sat Nov  7 22:19:22 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Sat, 7 Nov 2020 22:19:22 +0000
Subject: Searching on GitLab
Message-ID: <010f0175a4cae61d-0f0c4bad-4362-45db-83a4-6e23f4766470-000000@us-east-2.amazonses.com>

Hi all,

Some time ago, I set up a keyword bookmark (https://www-archive.mozilla.org/docs/end-user/keywords.html <https://www-archive.mozilla.org/docs/end-user/keywords.html>) to search in tickets and MRs, by using a Google "site:gitlab.haskell.org/ghc/ghc/issues/ <http://gitlab.haskell.org/ghc/ghc/issues/> %s" query. About a year ago, I noticed that the quality of results decreased to the point of uselessness, and I started to use GitLab's built-in search. This works fine, but it's not as good as Google's. Today, I discovered why the quality went down: GitLab changed its URLs. Previously, a ticket lived at e.g. gitlab.haskell.org/ghc/ghc/issues/1234 <http://gitlab.haskell.org/ghc/ghc/issues/1234>. Today, it lives at gitlab.haskell.org/ghc/ghc/-/issues/1234 <http://gitlab.haskell.org/ghc/ghc/-/issues/1234>. GitLab automatically redirects from the former to the latter, so old links/bookmarks still work great. But Google's search doesn't! The solution was easy: just update my keyword bookmarks to include the extra /-. Better search results, cooked up fresh. Perhaps you want some, too -- hence this email.

Enjoy,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201107/00f7fe32/attachment.html>

From b at chreekat.net  Tue Nov 17 06:47:18 2020
From: b at chreekat.net (Bryan Richter)
Date: Tue, 17 Nov 2020 08:47:18 +0200
Subject: Use of forall as a sigil
Message-ID: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>

Dear forall ghc-devs. ghc-devs,

As I read through the "Visible 'forall' in types of terms"
proposal[1], I stumbled over something that isn't relevant to the
proposal itself, so I thought I would bring it here.

Given

        f :: forall a. a -> a                   (1)

I intuitively understand the 'forall' in (1) to represent the phrase
"for all". I would read (1) as "For all objects a in Hask, f is some
relation from a to a."

After reading the proposal, I think my intuition may be wrong, since I
discovered `forall a ->`. This means something similar to, but
practically different from, `forall a.`. Thus it seems like 'forall'
is now simply used as a sigil to represent "here is where some special
parameter goes". It could as well be an emoji.

What's more, the practical difference between the two forms is *only*
distinguished by ` ->` versus `.`. That's putting quite a lot of
meaning into a rather small number of pixels, and further reduces any
original connection to meaning that 'forall' might have had.

I won't object to #281 based only on existing syntax, but I *do*
object to the existing syntax. :) Is this a hopeless situation, or is
there any possibility of bringing back meaning to the syntax of
"dependent quantifiers"?

-Bryan

[1]: https://github.com/ghc-proposals/ghc-proposals/pull/281

From rae at richarde.dev  Tue Nov 17 14:27:08 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 17 Nov 2020 14:27:08 +0000
Subject: Use of forall as a sigil
In-Reply-To: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
Message-ID: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>

Hi Bryan,

I don't think I understand what you're getting at here. The difference between `forall b .` and `forall b ->` is only that the choice of b must be made explicit. Importantly, a function of type e.g. `forall b -> b -> b` can *not* pattern-match on the choice of type; it can bind a variable that will be aliased to b, but it cannot pattern-match (say, against Int). Given this, can you describe how `forall b ->` violates your intuition for the keyword "forall"?

Thanks!
Richard

> On Nov 17, 2020, at 1:47 AM, Bryan Richter <b at chreekat.net> wrote:
> 
> Dear forall ghc-devs. ghc-devs,
> 
> As I read through the "Visible 'forall' in types of terms"
> proposal[1], I stumbled over something that isn't relevant to the
> proposal itself, so I thought I would bring it here.
> 
> Given
> 
>        f :: forall a. a -> a                   (1)
> 
> I intuitively understand the 'forall' in (1) to represent the phrase
> "for all". I would read (1) as "For all objects a in Hask, f is some
> relation from a to a."
> 
> After reading the proposal, I think my intuition may be wrong, since I
> discovered `forall a ->`. This means something similar to, but
> practically different from, `forall a.`. Thus it seems like 'forall'
> is now simply used as a sigil to represent "here is where some special
> parameter goes". It could as well be an emoji.
> 
> What's more, the practical difference between the two forms is *only*
> distinguished by ` ->` versus `.`. That's putting quite a lot of
> meaning into a rather small number of pixels, and further reduces any
> original connection to meaning that 'forall' might have had.
> 
> I won't object to #281 based only on existing syntax, but I *do*
> object to the existing syntax. :) Is this a hopeless situation, or is
> there any possibility of bringing back meaning to the syntax of
> "dependent quantifiers"?
> 
> -Bryan
> 
> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/281
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From christiaan.baaij at gmail.com  Wed Nov 18 09:07:49 2020
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Wed, 18 Nov 2020 10:07:49 +0100
Subject: Use of forall as a sigil
In-Reply-To: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
Message-ID: <CABzw7bWPwUpg5jcduHh9naTDzOEh-iAiMJa_QvT_fqXR_W1dEw@mail.gmail.com>

Reading proposal 281, I would be similarly confused.

In point 4 of section 4.1, primary change, it states that type constructors
are now allowed in the grammar of patterns; which if I understand correctly
is mostly a name-resolving thing.
Perhaps I read the proposal too quickly, but I couldn't find a sentence
anywhere that explicitly said that type-checking will subsequently throw an
error when name-resolution resolved a pattern to be a type constructor.

-- Christiaan

On Tue, 17 Nov 2020 at 15:27, Richard Eisenberg <rae at richarde.dev> wrote:

> Hi Bryan,
>
> I don't think I understand what you're getting at here. The difference
> between `forall b .` and `forall b ->` is only that the choice of b must be
> made explicit. Importantly, a function of type e.g. `forall b -> b -> b`
> can *not* pattern-match on the choice of type; it can bind a variable that
> will be aliased to b, but it cannot pattern-match (say, against Int). Given
> this, can you describe how `forall b ->` violates your intuition for the
> keyword "forall"?
>
> Thanks!
> Richard
>
> > On Nov 17, 2020, at 1:47 AM, Bryan Richter <b at chreekat.net> wrote:
> >
> > Dear forall ghc-devs. ghc-devs,
> >
> > As I read through the "Visible 'forall' in types of terms"
> > proposal[1], I stumbled over something that isn't relevant to the
> > proposal itself, so I thought I would bring it here.
> >
> > Given
> >
> >        f :: forall a. a -> a                   (1)
> >
> > I intuitively understand the 'forall' in (1) to represent the phrase
> > "for all". I would read (1) as "For all objects a in Hask, f is some
> > relation from a to a."
> >
> > After reading the proposal, I think my intuition may be wrong, since I
> > discovered `forall a ->`. This means something similar to, but
> > practically different from, `forall a.`. Thus it seems like 'forall'
> > is now simply used as a sigil to represent "here is where some special
> > parameter goes". It could as well be an emoji.
> >
> > What's more, the practical difference between the two forms is *only*
> > distinguished by ` ->` versus `.`. That's putting quite a lot of
> > meaning into a rather small number of pixels, and further reduces any
> > original connection to meaning that 'forall' might have had.
> >
> > I won't object to #281 based only on existing syntax, but I *do*
> > object to the existing syntax. :) Is this a hopeless situation, or is
> > there any possibility of bringing back meaning to the syntax of
> > "dependent quantifiers"?
> >
> > -Bryan
> >
> > [1]: https://github.com/ghc-proposals/ghc-proposals/pull/281
> > _______________________________________________
> > 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/20201118/a567357b/attachment.html>

From b at chreekat.net  Wed Nov 18 11:11:18 2020
From: b at chreekat.net (Bryan Richter)
Date: Wed, 18 Nov 2020 13:11:18 +0200
Subject: Use of forall as a sigil
In-Reply-To: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
Message-ID: <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>

Yeah, sorry, I think I'm in a little over my head here. :) But I think I
can ask a more answerable question now: how does one pronounce "forall a ->
a -> Int"?

Den tis 17 nov. 2020 16:27Richard Eisenberg <rae at richarde.dev> skrev:

> Hi Bryan,
>
> I don't think I understand what you're getting at here. The difference
> between `forall b .` and `forall b ->` is only that the choice of b must be
> made explicit. Importantly, a function of type e.g. `forall b -> b -> b`
> can *not* pattern-match on the choice of type; it can bind a variable that
> will be aliased to b, but it cannot pattern-match (say, against Int). Given
> this, can you describe how `forall b ->` violates your intuition for the
> keyword "forall"?
>
> Thanks!
> Richard
>
> > On Nov 17, 2020, at 1:47 AM, Bryan Richter <b at chreekat.net> wrote:
> >
> > Dear forall ghc-devs. ghc-devs,
> >
> > As I read through the "Visible 'forall' in types of terms"
> > proposal[1], I stumbled over something that isn't relevant to the
> > proposal itself, so I thought I would bring it here.
> >
> > Given
> >
> >        f :: forall a. a -> a                   (1)
> >
> > I intuitively understand the 'forall' in (1) to represent the phrase
> > "for all". I would read (1) as "For all objects a in Hask, f is some
> > relation from a to a."
> >
> > After reading the proposal, I think my intuition may be wrong, since I
> > discovered `forall a ->`. This means something similar to, but
> > practically different from, `forall a.`. Thus it seems like 'forall'
> > is now simply used as a sigil to represent "here is where some special
> > parameter goes". It could as well be an emoji.
> >
> > What's more, the practical difference between the two forms is *only*
> > distinguished by ` ->` versus `.`. That's putting quite a lot of
> > meaning into a rather small number of pixels, and further reduces any
> > original connection to meaning that 'forall' might have had.
> >
> > I won't object to #281 based only on existing syntax, but I *do*
> > object to the existing syntax. :) Is this a hopeless situation, or is
> > there any possibility of bringing back meaning to the syntax of
> > "dependent quantifiers"?
> >
> > -Bryan
> >
> > [1]: https://github.com/ghc-proposals/ghc-proposals/pull/281
> > _______________________________________________
> > 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/20201118/216b9390/attachment.html>

From stu126209 at mail.uni-kiel.de  Wed Nov 18 16:01:12 2020
From: stu126209 at mail.uni-kiel.de (Kai-Oliver Prott)
Date: Wed, 18 Nov 2020 17:01:12 +0100
Subject: Question about HsWrapper for constructors
Message-ID: <b621ca26-6ad1-7f4f-98f4-2bf4472e600b@mail.uni-kiel.de>

Hi all,

I've tried a development snapshot of GHC's master branch from the 
beginning of this month and I am curious about the reason for a specific 
change. I noticed that a simple program like

idNil :: [a] -> [a]
idNil [] = []

is internally represented (after type checking) as:

AbsBinds [] []
   {Exports: [idNil <= idNil2]
    Exported types: idNil :: forall a. [a] -> [a]
    Binds: idNil2 [] = (/\(@a2). [] @a2) @a

Can someone point me to a reason why the right side of idNil2 is not 
represented as [] @ a, like it was in GHC 8.10.1? I have not tried it 
with GHC 9.0. It is interesting to have a type lambda that is 
immediately followed by a type application.

Thanks,

Kai


From krz.gogolewski at gmail.com  Wed Nov 18 17:02:11 2020
From: krz.gogolewski at gmail.com (Krzysztof Gogolewski)
Date: Wed, 18 Nov 2020 18:02:11 +0100
Subject: Question about HsWrapper for constructors
In-Reply-To: <b621ca26-6ad1-7f4f-98f4-2bf4472e600b@mail.uni-kiel.de>
References: <b621ca26-6ad1-7f4f-98f4-2bf4472e600b@mail.uni-kiel.de>
Message-ID: <CA+h2LznB0MzkP6JQkM-NdBi48_MPSZZbTJEeD3+pMfgYszpEDA@mail.gmail.com>

Hi Kai,

This was changed with linear types.
In Core, the constructor Just has now the linear type forall a. a %1 -> Maybe a.
For backwards compatibility, every occurrence of Just is eta-expanded
to \(@a # m) (x :: a) -> Just @a x, so that it can be used in a
non-linear context.
In the case of [], this transformation adds an extra type parameter, which
doesn't change much.
The details are in return_data_con and in Note [Linear fields generalization]
in Tc/Gen/Head.hs.

Best,
Krzysztof

On Wed, Nov 18, 2020 at 5:01 PM Kai-Oliver Prott
<stu126209 at mail.uni-kiel.de> wrote:
>
> Hi all,
>
> I've tried a development snapshot of GHC's master branch from the
> beginning of this month and I am curious about the reason for a specific
> change. I noticed that a simple program like
>
> idNil :: [a] -> [a]
> idNil [] = []
>
> is internally represented (after type checking) as:
>
> AbsBinds [] []
>    {Exports: [idNil <= idNil2]
>     Exported types: idNil :: forall a. [a] -> [a]
>     Binds: idNil2 [] = (/\(@a2). [] @a2) @a
>
> Can someone point me to a reason why the right side of idNil2 is not
> represented as [] @ a, like it was in GHC 8.10.1? I have not tried it
> with GHC 9.0. It is interesting to have a type lambda that is
> immediately followed by a type application.
>
> Thanks,
>
> Kai
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From rae at richarde.dev  Wed Nov 18 17:50:38 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 18 Nov 2020 17:50:38 +0000
Subject: Use of forall as a sigil
In-Reply-To: <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
Message-ID: <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>

Hi Bryan,

First off, sorry if my first response was a bit snippy -- it wasn't meant to be, and I appreciate the angle you're taking in your question. I just didn't understand it!

This second question is easier to answer. I say "forall a arrow a arrow Int".

But I still think there may be a deeper question here left unanswered...

Richard

> On Nov 18, 2020, at 6:11 AM, Bryan Richter <b at chreekat.net> wrote:
> 
> Yeah, sorry, I think I'm in a little over my head here. :) But I think I can ask a more answerable question now: how does one pronounce "forall a -> a -> Int"?
> 
> Den tis 17 nov. 2020 16:27Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> skrev:
> Hi Bryan,
> 
> I don't think I understand what you're getting at here. The difference between `forall b .` and `forall b ->` is only that the choice of b must be made explicit. Importantly, a function of type e.g. `forall b -> b -> b` can *not* pattern-match on the choice of type; it can bind a variable that will be aliased to b, but it cannot pattern-match (say, against Int). Given this, can you describe how `forall b ->` violates your intuition for the keyword "forall"?
> 
> Thanks!
> Richard
> 
> > On Nov 17, 2020, at 1:47 AM, Bryan Richter <b at chreekat.net <mailto:b at chreekat.net>> wrote:
> > 
> > Dear forall ghc-devs. ghc-devs,
> > 
> > As I read through the "Visible 'forall' in types of terms"
> > proposal[1], I stumbled over something that isn't relevant to the
> > proposal itself, so I thought I would bring it here.
> > 
> > Given
> > 
> >        f :: forall a. a -> a                   (1)
> > 
> > I intuitively understand the 'forall' in (1) to represent the phrase
> > "for all". I would read (1) as "For all objects a in Hask, f is some
> > relation from a to a."
> > 
> > After reading the proposal, I think my intuition may be wrong, since I
> > discovered `forall a ->`. This means something similar to, but
> > practically different from, `forall a.`. Thus it seems like 'forall'
> > is now simply used as a sigil to represent "here is where some special
> > parameter goes". It could as well be an emoji.
> > 
> > What's more, the practical difference between the two forms is *only*
> > distinguished by ` ->` versus `.`. That's putting quite a lot of
> > meaning into a rather small number of pixels, and further reduces any
> > original connection to meaning that 'forall' might have had.
> > 
> > I won't object to #281 based only on existing syntax, but I *do*
> > object to the existing syntax. :) Is this a hopeless situation, or is
> > there any possibility of bringing back meaning to the syntax of
> > "dependent quantifiers"?
> > 
> > -Bryan
> > 
> > [1]: https://github.com/ghc-proposals/ghc-proposals/pull/281 <https://github.com/ghc-proposals/ghc-proposals/pull/281>
> > _______________________________________________
> > 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/20201118/91bc62df/attachment.html>

From iavor.diatchki at gmail.com  Wed Nov 18 18:08:06 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 18 Nov 2020 10:08:06 -0800
Subject: Use of forall as a sigil
In-Reply-To: <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>

Semantically, `forall a -> a -> Int` is the same as `forall a. a -> Int`.
The two only differ in how you use them:
  * For the first one, you have to explicitly provide the type to use for
`a` at every call site, while
  * for the second one, you usually omit the type and let GHC infer it.

So overall I think it's a pretty simple idea. For me it's hard to see that
from the text in #281, but I think a lot of the complexity there
is about a fancy notation for explicitly providing the type at call sites.

-Iavor



On Wed, Nov 18, 2020 at 9:51 AM Richard Eisenberg <rae at richarde.dev> wrote:

> Hi Bryan,
>
> First off, sorry if my first response was a bit snippy -- it wasn't meant
> to be, and I appreciate the angle you're taking in your question. I just
> didn't understand it!
>
> This second question is easier to answer. I say "forall a arrow a arrow
> Int".
>
> But I still think there may be a deeper question here left unanswered...
>
> Richard
>
> On Nov 18, 2020, at 6:11 AM, Bryan Richter <b at chreekat.net> wrote:
>
> Yeah, sorry, I think I'm in a little over my head here. :) But I think I
> can ask a more answerable question now: how does one pronounce "forall a ->
> a -> Int"?
>
> Den tis 17 nov. 2020 16:27Richard Eisenberg <rae at richarde.dev> skrev:
>
>> Hi Bryan,
>>
>> I don't think I understand what you're getting at here. The difference
>> between `forall b .` and `forall b ->` is only that the choice of b must be
>> made explicit. Importantly, a function of type e.g. `forall b -> b -> b`
>> can *not* pattern-match on the choice of type; it can bind a variable that
>> will be aliased to b, but it cannot pattern-match (say, against Int). Given
>> this, can you describe how `forall b ->` violates your intuition for the
>> keyword "forall"?
>>
>> Thanks!
>> Richard
>>
>> > On Nov 17, 2020, at 1:47 AM, Bryan Richter <b at chreekat.net> wrote:
>> >
>> > Dear forall ghc-devs. ghc-devs,
>> >
>> > As I read through the "Visible 'forall' in types of terms"
>> > proposal[1], I stumbled over something that isn't relevant to the
>> > proposal itself, so I thought I would bring it here.
>> >
>> > Given
>> >
>> >        f :: forall a. a -> a                   (1)
>> >
>> > I intuitively understand the 'forall' in (1) to represent the phrase
>> > "for all". I would read (1) as "For all objects a in Hask, f is some
>> > relation from a to a."
>> >
>> > After reading the proposal, I think my intuition may be wrong, since I
>> > discovered `forall a ->`. This means something similar to, but
>> > practically different from, `forall a.`. Thus it seems like 'forall'
>> > is now simply used as a sigil to represent "here is where some special
>> > parameter goes". It could as well be an emoji.
>> >
>> > What's more, the practical difference between the two forms is *only*
>> > distinguished by ` ->` versus `.`. That's putting quite a lot of
>> > meaning into a rather small number of pixels, and further reduces any
>> > original connection to meaning that 'forall' might have had.
>> >
>> > I won't object to #281 based only on existing syntax, but I *do*
>> > object to the existing syntax. :) Is this a hopeless situation, or is
>> > there any possibility of bringing back meaning to the syntax of
>> > "dependent quantifiers"?
>> >
>> > -Bryan
>> >
>> > [1]: https://github.com/ghc-proposals/ghc-proposals/pull/281
>> > _______________________________________________
>> > 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/20201118/15e8399c/attachment.html>

From carter.schonwald at gmail.com  Wed Nov 18 20:10:20 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 18 Nov 2020 14:10:20 -0600
Subject: Use of forall as a sigil
In-Reply-To: <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
Message-ID: <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>

I do think explaining it relative to the explicit vs implicit arg syntax of
agda function argument syntax.

f:  Forall a . B is used with f x. This relates to the new forall ->
syntax.

g: forall {c}. D is used either as f or f {x}, aka implicit or forcing it
to be explicit.  This maps to our usual Haskell forall with explicit {}
being the @ analogue

On Wed, Nov 18, 2020 at 12:09 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Semantically, `forall a -> a -> Int` is the same as `forall a. a -> Int`.
> The two only differ in how you use them:
>   * For the first one, you have to explicitly provide the type to use for
> `a` at every call site, while
>   * for the second one, you usually omit the type and let GHC infer it.
>
> So overall I think it's a pretty simple idea. For me it's hard to see that
> from the text in #281, but I think a lot of the complexity there
> is about a fancy notation for explicitly providing the type at call sites.
>
> -Iavor
>
>
>
> On Wed, Nov 18, 2020 at 9:51 AM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>> Hi Bryan,
>>
>> First off, sorry if my first response was a bit snippy -- it wasn't meant
>> to be, and I appreciate the angle you're taking in your question. I just
>> didn't understand it!
>>
>> This second question is easier to answer. I say "forall a arrow a arrow
>> Int".
>>
>> But I still think there may be a deeper question here left unanswered...
>>
>> Richard
>>
>> On Nov 18, 2020, at 6:11 AM, Bryan Richter <b at chreekat.net> wrote:
>>
>> Yeah, sorry, I think I'm in a little over my head here. :) But I think I
>> can ask a more answerable question now: how does one pronounce "forall a ->
>> a -> Int"?
>>
>> Den tis 17 nov. 2020 16:27Richard Eisenberg <rae at richarde.dev> skrev:
>>
>>> Hi Bryan,
>>>
>>> I don't think I understand what you're getting at here. The difference
>>> between `forall b .` and `forall b ->` is only that the choice of b must be
>>> made explicit. Importantly, a function of type e.g. `forall b -> b -> b`
>>> can *not* pattern-match on the choice of type; it can bind a variable that
>>> will be aliased to b, but it cannot pattern-match (say, against Int). Given
>>> this, can you describe how `forall b ->` violates your intuition for the
>>> keyword "forall"?
>>>
>>> Thanks!
>>> Richard
>>>
>>> > On Nov 17, 2020, at 1:47 AM, Bryan Richter <b at chreekat.net> wrote:
>>> >
>>> > Dear forall ghc-devs. ghc-devs,
>>> >
>>> > As I read through the "Visible 'forall' in types of terms"
>>> > proposal[1], I stumbled over something that isn't relevant to the
>>> > proposal itself, so I thought I would bring it here.
>>> >
>>> > Given
>>> >
>>> >        f :: forall a. a -> a                   (1)
>>> >
>>> > I intuitively understand the 'forall' in (1) to represent the phrase
>>> > "for all". I would read (1) as "For all objects a in Hask, f is some
>>> > relation from a to a."
>>> >
>>> > After reading the proposal, I think my intuition may be wrong, since I
>>> > discovered `forall a ->`. This means something similar to, but
>>> > practically different from, `forall a.`. Thus it seems like 'forall'
>>> > is now simply used as a sigil to represent "here is where some special
>>> > parameter goes". It could as well be an emoji.
>>> >
>>> > What's more, the practical difference between the two forms is *only*
>>> > distinguished by ` ->` versus `.`. That's putting quite a lot of
>>> > meaning into a rather small number of pixels, and further reduces any
>>> > original connection to meaning that 'forall' might have had.
>>> >
>>> > I won't object to #281 based only on existing syntax, but I *do*
>>> > object to the existing syntax. :) Is this a hopeless situation, or is
>>> > there any possibility of bringing back meaning to the syntax of
>>> > "dependent quantifiers"?
>>> >
>>> > -Bryan
>>> >
>>> > [1]: https://github.com/ghc-proposals/ghc-proposals/pull/281
>>> > _______________________________________________
>>> > 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/20201118/c4c923ae/attachment.html>

From liuyiyun at terpmail.umd.edu  Thu Nov 19 04:06:27 2020
From: liuyiyun at terpmail.umd.edu (Yiyun Liu)
Date: Wed, 18 Nov 2020 23:06:27 -0500
Subject: Correct way of extending the context of the typechecker
Message-ID: <8cc9968e-3776-f783-c00b-017f726d78cc@terpmail.umd.edu>

Hi ghc-devs,

Recently we've been trying to merge the typeclass branch of Liquid 
Haskell into the develop branch (link to the PR: 
https://github.com/ucsd-progsys/liquidhaskell/pull/1778). Since we want 
GHC to typecheck the refinements, we had to add some predefined logic 
symbols such as ==> to the global environment of GHC. In our branch, we 
use execStmt to add those extra symbols to the interactive context. This 
is no longer possible after LH becomes available as a GHC plugin because 
the plugin lives in TcRn. It seems that the only way is to directly 
interact with the typechecker and explicitly add the extra symbols to 
the context. It is not obvious to me how that can be done without 
accidentally breaking the invariants of the compiler.

I wonder if there are examples or certain files that I can look into to 
learn how to interact with the typechecker?  Adding the extra symbols is 
probably not that difficult, but I'd also want to acquire some general 
knowledge of how the typechecker works to further the integration 
between LH and GHC so we can remove some of the hacks on our end.

Thanks,

-Yiyun


From rae at richarde.dev  Thu Nov 19 04:20:40 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 19 Nov 2020 04:20:40 +0000
Subject: PSA: type checker plugins to be affected by upcoming changes to GHC
Message-ID: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>

Hi all,

I'm hard at work on two significant refactorings within GHC's constraint solver. The first is at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149. It removes flattening meta-variables and flattening skolems. This is a very nice simplification. Instead, it just reduces type families directly. My other patch (held up by the first) is at https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor and will remove Derived constraints, to be replaced by a little bit of cleverness in suppressing certain confusing error messages. My guess is that either or both of these will invalidate the current behavior of type-checker plugins. Sadly, this is not just a case of finding a new function that replicates the old behavior -- enough is changing under the hood that you might actually have to rewrite chunks of your code.

I have never written a type-checker plugin, and so I don't currently have advice for you. But if you are a plugin author affected by this change and want help, please reach out -- I would be happy to walk you through the changes, and then hopefully make a little video explaining the process to other plugin authors.

Neither patch will make it for 9.0, but I expect both to be in 9.2. There may be more where this came from (https://gitlab.haskell.org/ghc/ghc/-/issues/18965) in the future, but it's all for a good cause.

(I have bcc'd plugin authors that I'm aware of. Just adding this in case you're surprised at receiving this email.)

Thanks,
Richard

From ben at well-typed.com  Thu Nov 19 04:45:59 2020
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 18 Nov 2020 23:45:59 -0500
Subject: PSA: type checker plugins to be affected by upcoming changes to
 GHC
In-Reply-To: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
References: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
Message-ID: <97EFD8E9-8122-4971-AEA0-689D3C0CA3E9@well-typed.com>

Iavor and Christiaan are two plugin authors that come to mind.

Ideally the patch would also include some migration documentation in the release notes.

Cheers,

- Ben 

On November 18, 2020 11:20:40 PM EST, Richard Eisenberg <rae at richarde.dev> wrote:
>Hi all,
>
>I'm hard at work on two significant refactorings within GHC's
>constraint solver. The first is at
>https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149. It removes
>flattening meta-variables and flattening skolems. This is a very nice
>simplification. Instead, it just reduces type families directly. My
>other patch (held up by the first) is at
>https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor and will
>remove Derived constraints, to be replaced by a little bit of
>cleverness in suppressing certain confusing error messages. My guess is
>that either or both of these will invalidate the current behavior of
>type-checker plugins. Sadly, this is not just a case of finding a new
>function that replicates the old behavior -- enough is changing under
>the hood that you might actually have to rewrite chunks of your code.
>
>I have never written a type-checker plugin, and so I don't currently
>have advice for you. But if you are a plugin author affected by this
>change and want help, please reach out -- I would be happy to walk you
>through the changes, and then hopefully make a little video explaining
>the process to other plugin authors.
>
>Neither patch will make it for 9.0, but I expect both to be in 9.2.
>There may be more where this came from
>(https://gitlab.haskell.org/ghc/ghc/-/issues/18965) in the future, but
>it's all for a good cause.
>
>(I have bcc'd plugin authors that I'm aware of. Just adding this in
>case you're surprised at receiving this email.)
>
>Thanks,
>Richard
>_______________________________________________
>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/20201118/113b88e7/attachment.html>

From adam at well-typed.com  Thu Nov 19 09:14:30 2020
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 19 Nov 2020 09:14:30 +0000
Subject: PSA: type checker plugins to be affected by upcoming changes to
 GHC
In-Reply-To: <97EFD8E9-8122-4971-AEA0-689D3C0CA3E9@well-typed.com>
References: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
 <97EFD8E9-8122-4971-AEA0-689D3C0CA3E9@well-typed.com>
Message-ID: <ba4f86bf-784d-9ff7-a915-ddc4744bea06@well-typed.com>

Thanks Richard!

I'm happy to see this as I've always felt the flattening story to be
unnecessarily complex for type-checker plugins, and in fact uom-plugin
has been broken for a long time because of a previous GHC change to
flattening skolems.[1,2] I haven't checked but I am moderately hopeful
your work will at least make it easier to fix, if not fix it outright.

As part of removing Deriveds, do you plan to change the type-checker
plugin interface to drop the redundant argument? Although I suppose GHC
could simply pass an empty list to the plugin.

Ideally we would have a spec (or at least some tests!) for what
constraints get presented to plugins. The current implementation is
rather dependent on whatever GHC's solver happens to produce. In my
paper [3] I tried to specify plugins based on the published description
of OutsideIn(X), but that's far enough from the reality of GHC that it
isn't much help in practice. (One point it lacks is any treatment of
Deriveds, so I'm happy to see them go!)

Cheers,

Adam

[1] https://github.com/adamgundry/uom-plugin/issues/43
[2] https://gitlab.haskell.org/ghc/ghc/-/issues/15147
[3] https://adam.gundry.co.uk/pub/typechecker-plugins/




On 19/11/2020 04:45, Ben Gamari wrote:
> Iavor and Christiaan are two plugin authors that come to mind.
> 
> Ideally the patch would also include some migration documentation in the
> release notes.
> 
> Cheers,
> 
> - Ben
> 
> On November 18, 2020 11:20:40 PM EST, Richard Eisenberg
> <rae at richarde.dev> wrote:
> 
>     Hi all,
> 
>     I'm hard at work on two significant refactorings within GHC's constraint solver. The first is at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149. It removes flattening meta-variables and flattening skolems. This is a very nice simplification. Instead, it just reduces type families directly. My other patch (held up by the first) is at https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor and will remove Derived constraints, to be replaced by a little bit of cleverness in suppressing certain confusing error messages. My guess is that either or both of these will invalidate the current behavior of type-checker plugins. Sadly, this is not just a case of finding a new function that replicates the old behavior -- enough is changing under the hood that you might actually have to rewrite chunks of your code.
> 
>     I have never written a type-checker plugin, and so I don't currently have advice for you. But if you are a plugin author affected by this change and want help, please reach out -- I would be happy to walk you through the changes, and then hopefully make a little video explaining the process to other plugin authors.
> 
>     Neither patch will make it for 9.0, but I expect both to be in 9.2. There may be more where this came from (https://gitlab.haskell.org/ghc/ghc/-/issues/18965) in the future, but it's all for a good cause.
> 
>     (I have bcc'd plugin authors that I'm aware of. Just adding this in case you're surprised at receiving this email.)
> 
>     Thanks,
>     Richard



-- 
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 Nov 19 10:20:37 2020
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Thu, 19 Nov 2020 11:20:37 +0100
Subject: PSA: type checker plugins to be affected by upcoming changes to
 GHC
In-Reply-To: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
References: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
Message-ID: <CABzw7bU100ZYogrQzqMav=DYJdtKwKaVcLkq2uhKqeeDUk2eYQ@mail.gmail.com>

I always forget what flattening did/does. Is it the thing where it turns a
"complex" type family application:

F (G y) (H z) ~ a

into:

G y ~ p
H z ~ q
F p q ~ a

?

If so, then I'm all for removing that. Since I actually wrote/hacked a
function that "reverts" that process (for [G]ivens only):
https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens
Which I use in all of my plugins. (PS it should perhaps be called
"unflattenGiven"? like I said, I always get confused about flatten vs
unflatten).

On Thu, 19 Nov 2020 at 05:20, Richard Eisenberg <rae at richarde.dev> wrote:

> Hi all,
>
> I'm hard at work on two significant refactorings within GHC's constraint
> solver. The first is at
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149. It removes
> flattening meta-variables and flattening skolems. This is a very nice
> simplification. Instead, it just reduces type families directly. My other
> patch (held up by the first) is at
> https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor and will
> remove Derived constraints, to be replaced by a little bit of cleverness in
> suppressing certain confusing error messages. My guess is that either or
> both of these will invalidate the current behavior of type-checker plugins.
> Sadly, this is not just a case of finding a new function that replicates
> the old behavior -- enough is changing under the hood that you might
> actually have to rewrite chunks of your code.
>
> I have never written a type-checker plugin, and so I don't currently have
> advice for you. But if you are a plugin author affected by this change and
> want help, please reach out -- I would be happy to walk you through the
> changes, and then hopefully make a little video explaining the process to
> other plugin authors.
>
> Neither patch will make it for 9.0, but I expect both to be in 9.2. There
> may be more where this came from (
> https://gitlab.haskell.org/ghc/ghc/-/issues/18965) in the future, but
> it's all for a good cause.
>
> (I have bcc'd plugin authors that I'm aware of. Just adding this in case
> you're surprised at receiving this email.)
>
> Thanks,
> Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201119/32f49401/attachment.html>

From iavor.diatchki at gmail.com  Thu Nov 19 17:40:05 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 19 Nov 2020 09:40:05 -0800
Subject: PSA: type checker plugins to be affected by upcoming changes to
 GHC
In-Reply-To: <CABzw7bU100ZYogrQzqMav=DYJdtKwKaVcLkq2uhKqeeDUk2eYQ@mail.gmail.com>
References: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
 <CABzw7bU100ZYogrQzqMav=DYJdtKwKaVcLkq2uhKqeeDUk2eYQ@mail.gmail.com>
Message-ID: <CAGK9nuqiQRhvxo=FKup1iVK+cimWvCfJ778TjwuGf8TGuCsHWw@mail.gmail.com>

Hello,

I haven't worked on that stuff in Haskell for a long time, but here are
some thoughts:
  - I think plugins should generally be agnostic to the form of the
constraints they are given, thus flattening or not should not affect
them---after all, the user might have written the constraints in the
"flattened" form in the first place.  So I think a plugin needs to convert
the constraints to whatever form it assumes anyways.
  - I always thought that derived constraints were a pretty clever way for
disseminating information in the constraint solver, is there a note
somewhere on what's going to be the new mechanism?

-Iavor


On Thu, Nov 19, 2020 at 2:21 AM Christiaan Baaij <christiaan.baaij at gmail.com>
wrote:

> I always forget what flattening did/does. Is it the thing where it turns a
> "complex" type family application:
>
> F (G y) (H z) ~ a
>
> into:
>
> G y ~ p
> H z ~ q
> F p q ~ a
>
> ?
>
> If so, then I'm all for removing that. Since I actually wrote/hacked a
> function that "reverts" that process (for [G]ivens only):
> https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens
> Which I use in all of my plugins. (PS it should perhaps be called
> "unflattenGiven"? like I said, I always get confused about flatten vs
> unflatten).
>
> On Thu, 19 Nov 2020 at 05:20, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> Hi all,
>>
>> I'm hard at work on two significant refactorings within GHC's constraint
>> solver. The first is at
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149. It removes
>> flattening meta-variables and flattening skolems. This is a very nice
>> simplification. Instead, it just reduces type families directly. My other
>> patch (held up by the first) is at
>> https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor and will
>> remove Derived constraints, to be replaced by a little bit of cleverness in
>> suppressing certain confusing error messages. My guess is that either or
>> both of these will invalidate the current behavior of type-checker plugins.
>> Sadly, this is not just a case of finding a new function that replicates
>> the old behavior -- enough is changing under the hood that you might
>> actually have to rewrite chunks of your code.
>>
>> I have never written a type-checker plugin, and so I don't currently have
>> advice for you. But if you are a plugin author affected by this change and
>> want help, please reach out -- I would be happy to walk you through the
>> changes, and then hopefully make a little video explaining the process to
>> other plugin authors.
>>
>> Neither patch will make it for 9.0, but I expect both to be in 9.2. There
>> may be more where this came from (
>> https://gitlab.haskell.org/ghc/ghc/-/issues/18965) in the future, but
>> it's all for a good cause.
>>
>> (I have bcc'd plugin authors that I'm aware of. Just adding this in case
>> you're surprised at receiving this email.)
>>
>> 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/20201119/0d245d3a/attachment.html>

From rae at richarde.dev  Thu Nov 19 19:01:43 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 19 Nov 2020 19:01:43 +0000
Subject: PSA: type checker plugins to be affected by upcoming changes to
 GHC
In-Reply-To: <ba4f86bf-784d-9ff7-a915-ddc4744bea06@well-typed.com>
References: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
 <97EFD8E9-8122-4971-AEA0-689D3C0CA3E9@well-typed.com>
 <ba4f86bf-784d-9ff7-a915-ddc4744bea06@well-typed.com>
Message-ID: <010f0175e1e2442e-ca351fd7-f3d1-42cb-8234-447c9606e796-000000@us-east-2.amazonses.com>



> On Nov 19, 2020, at 4:14 AM, Adam Gundry <adam at well-typed.com> wrote:
> 
> As part of removing Deriveds, do you plan to change the type-checker
> plugin interface to drop the redundant argument? Although I suppose GHC
> could simply pass an empty list to the plugin.

No -- I think we'll just remove the unused parameter. So much is changing in this space that the tiny bit of back-compat leaving that parameter would grant is a false promise.

> 
> Ideally we would have a spec (or at least some tests!) for what
> constraints get presented to plugins. The current implementation is
> rather dependent on whatever GHC's solver happens to produce. In my
> paper [3] I tried to specify plugins based on the published description
> of OutsideIn(X), but that's far enough from the reality of GHC that it
> isn't much help in practice. (One point it lacks is any treatment of
> Deriveds, so I'm happy to see them go!)

Yes. But this is really hard, and it would likely make e.g. my simplifications harder to execute on. (That is, it would be nice, but it wouldn't be free.) I think that maintaining this would require the extra labor of someone more familiar with the world of plugins... :)

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

From rae at richarde.dev  Thu Nov 19 19:04:36 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 19 Nov 2020 19:04:36 +0000
Subject: PSA: type checker plugins to be affected by upcoming changes to
 GHC
In-Reply-To: <CABzw7bU100ZYogrQzqMav=DYJdtKwKaVcLkq2uhKqeeDUk2eYQ@mail.gmail.com>
References: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
 <CABzw7bU100ZYogrQzqMav=DYJdtKwKaVcLkq2uhKqeeDUk2eYQ@mail.gmail.com>
Message-ID: <010f0175e1e4e7cf-33abf198-fa95-45ec-823f-38e65445a05d-000000@us-east-2.amazonses.com>



> On Nov 19, 2020, at 5:20 AM, Christiaan Baaij <christiaan.baaij at gmail.com> wrote:
> 
> I always forget what flattening did/does. Is it the thing where it turns a "complex" type family application:
> 
> F (G y) (H z) ~ a
> 
> into:
> 
> G y ~ p
> H z ~ q
> F p q ~ a
> 
> ?

Yes, but it's worse. It would actually leave us with

G y ~ p
H z ~ q
F p q ~ r
r ~ a

> 
> If so, then I'm all for removing that. Since I actually wrote/hacked a function that "reverts" that process (for [G]ivens only): https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens <https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens>
> Which I use in all of my plugins. (PS it should perhaps be called "unflattenGiven"? like I said, I always get confused about flatten vs unflatten).

Yes, this would be unflattening.

Glad to know this would work well with your plugins. :)

Richard

> 
> On Thu, 19 Nov 2020 at 05:20, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> Hi all,
> 
> I'm hard at work on two significant refactorings within GHC's constraint solver. The first is at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149>. It removes flattening meta-variables and flattening skolems. This is a very nice simplification. Instead, it just reduces type families directly. My other patch (held up by the first) is at https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor <https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor> and will remove Derived constraints, to be replaced by a little bit of cleverness in suppressing certain confusing error messages. My guess is that either or both of these will invalidate the current behavior of type-checker plugins. Sadly, this is not just a case of finding a new function that replicates the old behavior -- enough is changing under the hood that you might actually have to rewrite chunks of your code.
> 
> I have never written a type-checker plugin, and so I don't currently have advice for you. But if you are a plugin author affected by this change and want help, please reach out -- I would be happy to walk you through the changes, and then hopefully make a little video explaining the process to other plugin authors.
> 
> Neither patch will make it for 9.0, but I expect both to be in 9.2. There may be more where this came from (https://gitlab.haskell.org/ghc/ghc/-/issues/18965 <https://gitlab.haskell.org/ghc/ghc/-/issues/18965>) in the future, but it's all for a good cause.
> 
> (I have bcc'd plugin authors that I'm aware of. Just adding this in case you're surprised at receiving this email.)
> 
> Thanks,
> Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201119/40fa982e/attachment.html>

From b at chreekat.net  Thu Nov 19 19:18:17 2020
From: b at chreekat.net (Bryan Richter)
Date: Thu, 19 Nov 2020 21:18:17 +0200
Subject: Use of forall as a sigil
In-Reply-To: <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
 <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
Message-ID: <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>

Thanks for the replies! Let's see if I can make a stab at those deeper
questions now.

I'm playing a form of devil's advocate here, dissecting the syntax
with my intuition as a ghc *user*, and trying to bridge the gap to how
ghc *devs* understand it.

So correct me if I'm wrong: from an implementation perspective,
`forall a. a -> Int` is a function of two arguments, one of which can
be elided, while `forall a -> a -> Int` is a function of two
arguments, all of which must be provided.

If that's right, then it bumps into my intuition, which says that the
former is a function of only one argument. I never thought of `f @Int`
as partial function application, for instance. :) Is my intuition
leading me astray? *Should* I consider both functions as having two
arguments? If so, is that somehow "mathematically true" (a very
not-mathematical phrase, haha), or is it just an "implementation
detail"?


So that's one avenue of query I have, but it's actually not the one I
started off with. Focusing on the simpler case of `forall a -> a`,
which is a function of one argument, I take issue with how the
quantification is packed into the syntax for the argument, itself.
I.e., my intuition tells me this function is valid for all types,
takes the name of a type as an argument, and returns a value of that
type, which is three distinct pieces of information. I'd expect a
syntax like `forall a. elem x a. a -> x`, or maybe `forall a. nameof a
-> a`. The packing and punning conspire to make the syntax seem overly
clever. If I had to explain `forall a -> a` to one of my
Haskell-curious colleagues, I'd have to say "Oh that means you pass
the name of a type to the function" -- something they'd have no chance
of figuring out on their own! The 'forall' comes across as
meaningless. (Case in point: I had no idea what the syntax meant when
I saw it -- but I'm already invested enough to go digging.)

I guess my question, then, is if there is some way to make this syntax
more intuitive for users!

On Wed, Nov 18, 2020 at 10:10 PM Carter Schonwald
<carter.schonwald at gmail.com> wrote:
>
> I do think explaining it relative to the explicit vs implicit arg syntax of agda function argument syntax.
>
> f:  Forall a . B is used with f x. This relates to the new forall -> syntax.
>
> g: forall {c}. D is used either as f or f {x}, aka implicit or forcing it to be explicit.  This maps to our usual Haskell forall with explicit {} being the @ analogue
>
> On Wed, Nov 18, 2020 at 12:09 PM Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
>>
>> Semantically, `forall a -> a -> Int` is the same as `forall a. a -> Int`.  The two only differ in how you use them:
>>   * For the first one, you have to explicitly provide the type to use for `a` at every call site, while
>>   * for the second one, you usually omit the type and let GHC infer it.
>>
>> So overall I think it's a pretty simple idea. For me it's hard to see that from the text in #281, but I think a lot of the complexity there
>> is about a fancy notation for explicitly providing the type at call sites.
>>
>> -Iavor
>>
>>
>>
>> On Wed, Nov 18, 2020 at 9:51 AM Richard Eisenberg <rae at richarde.dev> wrote:
>>>
>>> Hi Bryan,
>>>
>>> First off, sorry if my first response was a bit snippy -- it wasn't meant to be, and I appreciate the angle you're taking in your question. I just didn't understand it!
>>>
>>> This second question is easier to answer. I say "forall a arrow a arrow Int".
>>>
>>> But I still think there may be a deeper question here left unanswered...
>>>
>>> Richard
>>>
>>> On Nov 18, 2020, at 6:11 AM, Bryan Richter <b at chreekat.net> wrote:
>>>
>>> Yeah, sorry, I think I'm in a little over my head here. :) But I think I can ask a more answerable question now: how does one pronounce "forall a -> a -> Int"?
>>>
>>> Den tis 17 nov. 2020 16:27Richard Eisenberg <rae at richarde.dev> skrev:
>>>>
>>>> Hi Bryan,
>>>>
>>>> I don't think I understand what you're getting at here. The difference between `forall b .` and `forall b ->` is only that the choice of b must be made explicit. Importantly, a function of type e.g. `forall b -> b -> b` can *not* pattern-match on the choice of type; it can bind a variable that will be aliased to b, but it cannot pattern-match (say, against Int). Given this, can you describe how `forall b ->` violates your intuition for the keyword "forall"?
>>>>
>>>> Thanks!
>>>> Richard
>>>>
>>>> > On Nov 17, 2020, at 1:47 AM, Bryan Richter <b at chreekat.net> wrote:
>>>> >
>>>> > Dear forall ghc-devs. ghc-devs,
>>>> >
>>>> > As I read through the "Visible 'forall' in types of terms"
>>>> > proposal[1], I stumbled over something that isn't relevant to the
>>>> > proposal itself, so I thought I would bring it here.
>>>> >
>>>> > Given
>>>> >
>>>> >        f :: forall a. a -> a                   (1)
>>>> >
>>>> > I intuitively understand the 'forall' in (1) to represent the phrase
>>>> > "for all". I would read (1) as "For all objects a in Hask, f is some
>>>> > relation from a to a."
>>>> >
>>>> > After reading the proposal, I think my intuition may be wrong, since I
>>>> > discovered `forall a ->`. This means something similar to, but
>>>> > practically different from, `forall a.`. Thus it seems like 'forall'
>>>> > is now simply used as a sigil to represent "here is where some special
>>>> > parameter goes". It could as well be an emoji.
>>>> >
>>>> > What's more, the practical difference between the two forms is *only*
>>>> > distinguished by ` ->` versus `.`. That's putting quite a lot of
>>>> > meaning into a rather small number of pixels, and further reduces any
>>>> > original connection to meaning that 'forall' might have had.
>>>> >
>>>> > I won't object to #281 based only on existing syntax, but I *do*
>>>> > object to the existing syntax. :) Is this a hopeless situation, or is
>>>> > there any possibility of bringing back meaning to the syntax of
>>>> > "dependent quantifiers"?
>>>> >
>>>> > -Bryan
>>>> >
>>>> > [1]: https://github.com/ghc-proposals/ghc-proposals/pull/281
>>>> > _______________________________________________
>>>> > 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
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Fri Nov 20 09:02:59 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 20 Nov 2020 09:02:59 +0000
Subject: Correct way of extending the context of the typechecker
In-Reply-To: <8cc9968e-3776-f783-c00b-017f726d78cc@terpmail.umd.edu>
References: <8cc9968e-3776-f783-c00b-017f726d78cc@terpmail.umd.edu>
Message-ID: <PR3PR83MB0475A0A1D0682763F049B724ADFF0@PR3PR83MB0475.EURPRD83.prod.outlook.com>

Yiyun

You might need to explain in a bit more detail.

The simplest thing may be this.

* Define, say, (==>) in some ordinary Haskell source module,
  say Liquid.Haskell

* Look up "Liquid.Haskell.==>", to get its Name, via
  GHC.Iface.Env.lookupOrig

* Then you can look up that Name, via GHC.Tc.Utils.Env.tcLookupGlobal
  This should load the interface for Liquid.Haskell, if it isn't
  already loaded.

Simon

|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Yiyun Liu
|  Sent: 19 November 2020 04:06
|  To: ghc-devs at haskell.org
|  Cc: niki.vazou <niki.vazou at imdea.org>; James Parker
|  <jp at jamesparker.me>
|  Subject: Correct way of extending the context of the typechecker
|  
|  Hi ghc-devs,
|  
|  Recently we've been trying to merge the typeclass branch of Liquid
|  Haskell into the develop branch (link to the PR:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fucsd-
|  progsys%2Fliquidhaskell%2Fpull%2F1778&amp;data=04%7C01%7Csimonpj%40mic
|  rosoft.com%7C8ffb59d6e2534efa91d108d88c408d6c%7C72f988bf86f141af91ab2d
|  7cd011db47%7C1%7C1%7C637413556756006684%7CUnknown%7CTWFpbGZsb3d8eyJWIj
|  oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am
|  p;sdata=pl2EqO3TwGC6Br1dQJa5Ej3WDQzN1vngy7HG9A7d9dc%3D&amp;reserved=0)
|  . Since we want GHC to typecheck the refinements, we had to add some
|  predefined logic symbols such as ==> to the global environment of GHC.
|  In our branch, we use execStmt to add those extra symbols to the
|  interactive context. This is no longer possible after LH becomes
|  available as a GHC plugin because the plugin lives in TcRn. It seems
|  that the only way is to directly interact with the typechecker and
|  explicitly add the extra symbols to the context. It is not obvious to
|  me how that can be done without accidentally breaking the invariants
|  of the compiler.
|  
|  I wonder if there are examples or certain files that I can look into
|  to learn how to interact with the typechecker?  Adding the extra
|  symbols is probably not that difficult, but I'd also want to acquire
|  some general knowledge of how the typechecker works to further the
|  integration between LH and GHC so we can remove some of the hacks on
|  our end.
|  
|  Thanks,
|  
|  -Yiyun
|  
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
|  haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C8ffb59d6e2534efa91d1
|  08d88c408d6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637413556756
|  006684%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
|  BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=heNWVmVkbhTgW1n9kdoKgXL0K
|  JICoORJOK97uJlEyH0%3D&amp;reserved=0

From rae at richarde.dev  Fri Nov 20 19:43:22 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 20 Nov 2020 19:43:22 +0000
Subject: PSA: type checker plugins to be affected by upcoming changes to
 GHC
In-Reply-To: <CAGK9nuqiQRhvxo=FKup1iVK+cimWvCfJ778TjwuGf8TGuCsHWw@mail.gmail.com>
References: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
 <CABzw7bU100ZYogrQzqMav=DYJdtKwKaVcLkq2uhKqeeDUk2eYQ@mail.gmail.com>
 <CAGK9nuqiQRhvxo=FKup1iVK+cimWvCfJ778TjwuGf8TGuCsHWw@mail.gmail.com>
Message-ID: <010f0175e72ec24f-c12ce71e-4192-4f37-befa-afb1a9b409d5-000000@us-east-2.amazonses.com>



> On Nov 19, 2020, at 12:40 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hello,
> 
> I haven't worked on that stuff in Haskell for a long time, but here are some thoughts:
>   - I think plugins should generally be agnostic to the form of the constraints they are given, thus flattening or not should not affect them---after all, the user might have written the constraints in the "flattened" form in the first place.  So I think a plugin needs to convert the constraints to whatever form it assumes anyways.
>   - I always thought that derived constraints were a pretty clever way for disseminating information in the constraint solver, is there a note somewhere on what's going to be the new mechanism?

This Note (https://gitlab.haskell.org/ghc/ghc/-/blob/wip/derived-refactor/compiler/GHC/Tc/Types/Constraint.hs#L1678) is the best I can offer, though it may be out of date. In the final version of the patch, that Note will naturally be updated. Essentially, the new plan is just to use Wanteds instead of Deriveds, which will achieve the same goal (but do not need to be distinct from Deriveds).

Richard

> 
> -Iavor
> 
> 
> On Thu, Nov 19, 2020 at 2:21 AM Christiaan Baaij <christiaan.baaij at gmail.com <mailto:christiaan.baaij at gmail.com>> wrote:
> I always forget what flattening did/does. Is it the thing where it turns a "complex" type family application:
> 
> F (G y) (H z) ~ a
> 
> into:
> 
> G y ~ p
> H z ~ q
> F p q ~ a
> 
> ?
> 
> If so, then I'm all for removing that. Since I actually wrote/hacked a function that "reverts" that process (for [G]ivens only): https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens <https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens>
> Which I use in all of my plugins. (PS it should perhaps be called "unflattenGiven"? like I said, I always get confused about flatten vs unflatten).
> 
> On Thu, 19 Nov 2020 at 05:20, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> Hi all,
> 
> I'm hard at work on two significant refactorings within GHC's constraint solver. The first is at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149>. It removes flattening meta-variables and flattening skolems. This is a very nice simplification. Instead, it just reduces type families directly. My other patch (held up by the first) is at https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor <https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor> and will remove Derived constraints, to be replaced by a little bit of cleverness in suppressing certain confusing error messages. My guess is that either or both of these will invalidate the current behavior of type-checker plugins. Sadly, this is not just a case of finding a new function that replicates the old behavior -- enough is changing under the hood that you might actually have to rewrite chunks of your code.
> 
> I have never written a type-checker plugin, and so I don't currently have advice for you. But if you are a plugin author affected by this change and want help, please reach out -- I would be happy to walk you through the changes, and then hopefully make a little video explaining the process to other plugin authors.
> 
> Neither patch will make it for 9.0, but I expect both to be in 9.2. There may be more where this came from (https://gitlab.haskell.org/ghc/ghc/-/issues/18965 <https://gitlab.haskell.org/ghc/ghc/-/issues/18965>) in the future, but it's all for a good cause.
> 
> (I have bcc'd plugin authors that I'm aware of. Just adding this in case you're surprised at receiving this email.)
> 
> 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 <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/20201120/12fbd7d3/attachment.html>

From rae at richarde.dev  Fri Nov 20 20:56:03 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 20 Nov 2020 20:56:03 +0000
Subject: Use of forall as a sigil
In-Reply-To: <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
 <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
 <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>
Message-ID: <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com>

Hi Bryan,

Thanks for this longer post -- it's very helpful to see this with fresh eyes.


> On Nov 19, 2020, at 2:18 PM, Bryan Richter <b at chreekat.net> wrote:
> 
> So correct me if I'm wrong: from an implementation perspective,
> `forall a. a -> Int` is a function of two arguments, one of which can
> be elided, while `forall a -> a -> Int` is a function of two
> arguments, all of which must be provided.

Yes, that's how I read these.

> 
> If that's right, then it bumps into my intuition, which says that the
> former is a function of only one argument. I never thought of `f @Int`
> as partial function application, for instance. :) Is my intuition
> leading me astray? *Should* I consider both functions as having two
> arguments? If so, is that somehow "mathematically true" (a very
> not-mathematical phrase, haha), or is it just an "implementation
> detail"?

I don't think there's one right answer here. And I'm not quite sure how to interpret "mathematically true". The best I can get is that, if we consider System F (a direct inspiration for Haskell's type system), then both functions really do take 2 arguments (as they do in GHC Core).

> 
> 
> So that's one avenue of query I have, but it's actually not the one I
> started off with. Focusing on the simpler case of `forall a -> a`,
> which is a function of one argument, I take issue with how the
> quantification is packed into the syntax for the argument, itself.
> I.e., my intuition tells me this function is valid for all types,
> takes the name of a type as an argument, and returns a value of that
> type, which is three distinct pieces of information. I'd expect a
> syntax like `forall a. elem x a. a -> x`, or maybe `forall a. nameof a
> -> a`. The packing and punning conspire to make the syntax seem overly
> clever.

How do you feel about

> f :: forall (a :: Type) -> a

or

> g :: (a :: Type) -> a

Somehow, for me too, having the type of `a` listed makes it clearer. The syntax for f echoes that in Coq, a long-standing dependently typed language, but it uses , instead of ->. The type of `a` is optional. (An implicit parameter is put in braces.) The syntax for g echoes that in Agda and Idris; the type of `a` is not optional. Haskell cannot use the syntax for `g`, because it looks like a kind annotation.

In the end, I've never loved the forall ... -> syntax, but I've never seen anything better. The suggestions you make are akin to those in https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-727907040. This alternative might work out, but I've never seen this approach taken in another language, and it would be quite different from what we have today.


> If I had to explain `forall a -> a` to one of my
> Haskell-curious colleagues, I'd have to say "Oh that means you pass
> the name of a type to the function" -- something they'd have no chance
> of figuring out on their own! The 'forall' comes across as
> meaningless. (Case in point: I had no idea what the syntax meant when
> I saw it -- but I'm already invested enough to go digging.)

I agree that the new syntax is not adequately self-describing.

> 
> I guess my question, then, is if there is some way to make this syntax
> more intuitive for users!

I agree! But I somehow don't think separating out all the pieces will make it easier, in the end.

Richard

> 
> On Wed, Nov 18, 2020 at 10:10 PM Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
>> 
>> I do think explaining it relative to the explicit vs implicit arg syntax of agda function argument syntax.
>> 
>> f:  Forall a . B is used with f x. This relates to the new forall -> syntax.
>> 
>> g: forall {c}. D is used either as f or f {x}, aka implicit or forcing it to be explicit.  This maps to our usual Haskell forall with explicit {} being the @ analogue
>> 
>> On Wed, Nov 18, 2020 at 12:09 PM Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
>>> 
>>> Semantically, `forall a -> a -> Int` is the same as `forall a. a -> Int`.  The two only differ in how you use them:
>>>  * For the first one, you have to explicitly provide the type to use for `a` at every call site, while
>>>  * for the second one, you usually omit the type and let GHC infer it.
>>> 
>>> So overall I think it's a pretty simple idea. For me it's hard to see that from the text in #281, but I think a lot of the complexity there
>>> is about a fancy notation for explicitly providing the type at call sites.
>>> 
>>> -Iavor
>>> 
>>> 
>>> 
>>> On Wed, Nov 18, 2020 at 9:51 AM Richard Eisenberg <rae at richarde.dev> wrote:
>>>> 
>>>> Hi Bryan,
>>>> 
>>>> First off, sorry if my first response was a bit snippy -- it wasn't meant to be, and I appreciate the angle you're taking in your question. I just didn't understand it!
>>>> 
>>>> This second question is easier to answer. I say "forall a arrow a arrow Int".
>>>> 
>>>> But I still think there may be a deeper question here left unanswered...
>>>> 
>>>> Richard
>>>> 
>>>> On Nov 18, 2020, at 6:11 AM, Bryan Richter <b at chreekat.net> wrote:
>>>> 
>>>> Yeah, sorry, I think I'm in a little over my head here. :) But I think I can ask a more answerable question now: how does one pronounce "forall a -> a -> Int"?
>>>> 
>>>> Den tis 17 nov. 2020 16:27Richard Eisenberg <rae at richarde.dev> skrev:
>>>>> 
>>>>> Hi Bryan,
>>>>> 
>>>>> I don't think I understand what you're getting at here. The difference between `forall b .` and `forall b ->` is only that the choice of b must be made explicit. Importantly, a function of type e.g. `forall b -> b -> b` can *not* pattern-match on the choice of type; it can bind a variable that will be aliased to b, but it cannot pattern-match (say, against Int). Given this, can you describe how `forall b ->` violates your intuition for the keyword "forall"?
>>>>> 
>>>>> Thanks!
>>>>> Richard
>>>>> 
>>>>>> On Nov 17, 2020, at 1:47 AM, Bryan Richter <b at chreekat.net> wrote:
>>>>>> 
>>>>>> Dear forall ghc-devs. ghc-devs,
>>>>>> 
>>>>>> As I read through the "Visible 'forall' in types of terms"
>>>>>> proposal[1], I stumbled over something that isn't relevant to the
>>>>>> proposal itself, so I thought I would bring it here.
>>>>>> 
>>>>>> Given
>>>>>> 
>>>>>>       f :: forall a. a -> a                   (1)
>>>>>> 
>>>>>> I intuitively understand the 'forall' in (1) to represent the phrase
>>>>>> "for all". I would read (1) as "For all objects a in Hask, f is some
>>>>>> relation from a to a."
>>>>>> 
>>>>>> After reading the proposal, I think my intuition may be wrong, since I
>>>>>> discovered `forall a ->`. This means something similar to, but
>>>>>> practically different from, `forall a.`. Thus it seems like 'forall'
>>>>>> is now simply used as a sigil to represent "here is where some special
>>>>>> parameter goes". It could as well be an emoji.
>>>>>> 
>>>>>> What's more, the practical difference between the two forms is *only*
>>>>>> distinguished by ` ->` versus `.`. That's putting quite a lot of
>>>>>> meaning into a rather small number of pixels, and further reduces any
>>>>>> original connection to meaning that 'forall' might have had.
>>>>>> 
>>>>>> I won't object to #281 based only on existing syntax, but I *do*
>>>>>> object to the existing syntax. :) Is this a hopeless situation, or is
>>>>>> there any possibility of bringing back meaning to the syntax of
>>>>>> "dependent quantifiers"?
>>>>>> 
>>>>>> -Bryan
>>>>>> 
>>>>>> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/281
>>>>>> _______________________________________________
>>>>>> 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
>> 
>> _______________________________________________
>> 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 jakob.bruenker at gmail.com  Sun Nov 22 03:38:42 2020
From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=)
Date: Sun, 22 Nov 2020 04:38:42 +0100
Subject: Adding a way to reduce type families in type errors
Message-ID: <CAJjQ6oMxZV79DsKuuv-XfPLYe3Qcc2EFC7TTXTums3nqxy0hOQ@mail.gmail.com>

Hi all,

While there is a way to expand type synonyms in type errors
(-fprint-expanded-synonyms), as far as I know, the same doesn't exist for
type families. For example, the following

type family Foo a where Foo Int = String
type family Bar a :: Maybe (Foo Int) where Bar a = '()

results in the error

Expected kind `Maybe (Foo Int)', but '() has kind `()'

where I'd like to see "Expected kind `Maybe String'".

I'd be interested in trying my hand at implementing a way to see this,
either by adding it to -fprint-expanded-synonyms, or as a new flag.

Three questions:
 - Is there already a way to do this that I'm missing?
 - Are there reasons for why this would be a bad idea?
 - Would a proposal be necessary for this?

Thanks,
Jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201122/88a5229d/attachment.html>

From andrey.mokhov at newcastle.ac.uk  Sun Nov 22 11:23:05 2020
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Sun, 22 Nov 2020 11:23:05 +0000
Subject: Use of forall as a sigil
Message-ID: <LNXP265MB141927F470139DD3AE7B6B08A5FD0@LNXP265MB1419.GBRP265.PROD.OUTLOOK.COM>

Hi Richard,

> In the end, I've never loved the forall ... -> syntax, but I've never seen
> anything better.

What about the forall @a. syntax?

For example:

  sizeOf :: forall @a. Sized a => Int

We already use @ to explicitly specify types, so it seems natural mark type parameters that must be explicitly specified with @ too.

Here's how one would read it: "for all explicitly specified a, ..."

Apologies if this has been discussed and I missed it. It doesn't seem to be mentioned in the Alternatives section of the proposal but perhaps it will just never work for some reason.

Cheers,
Andrey


From jan at vanbruegge.de  Sun Nov 22 11:49:13 2020
From: jan at vanbruegge.de (=?UTF-8?Q?Jan_van_Br=c3=bcgge?=)
Date: Sun, 22 Nov 2020 12:49:13 +0100
Subject: Questions about System F and data types
Message-ID: <412bc033-6bae-e105-c819-b825a4434e12@vanbruegge.de>

Hi,

I know that this is probably not the correct place to ask as my question
is not directly related to GHC itself, but I thought here are the people
that can most likely answer this.

To better understand PL papers, especially those involving System Fc and
its extensions, I started to write a formal proof of type safety
including alpha-equivalence. Currently I have a complete proof for
System F <https://github.com/jvanbruegge/isabelle-lambda-calculus>
(without coercions and data types yet). I mainly used the System Fc
paper
<https://www.microsoft.com/en-us/research/wp-content/uploads/2007/01/tldi22-sulzmann-with-appendix.pdf>
as reference, ignoring all the parts about coercions.

1. In the Fc paper, the rule `AppT` has a judgement delta as assumption,
which does not exist. I assumed the `ty` judgement was meant there by
looking at the arguments. Is this correct?

2. In the `Abs` rule, the type of the variable is required to be valid
and of kind star by the judgement `ty`. In the `Let` rule, this
assumption is missing. I tried it like that, but was not able to
complete the proofs. Is such an assumption missing there or should I be
able to proof it without?

3. In the Fc paper, the types and kinds of datatype declarations are
added to the context with a separate judgement that interprets the
datatype declarations. In the System Fc pro paper
<https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/p53-yorgey.pdf?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fext-f%2Fpromotion.pdf>
(from what I can tell) those types and kinds are assumed to be already
part of the initial context. At the moment I prove progress against the
empty context, so I guess I would have to relax that to an initial
context that only contains types and kinds of type constants and nothing
else. Is that correct? What is here the "best practice" in terms of PL
research?

Thank you all
Jan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201122/61ee0a06/attachment.html>

From john.ericson at obsidian.systems  Sun Nov 22 16:40:51 2020
From: john.ericson at obsidian.systems (John Ericson)
Date: Sun, 22 Nov 2020 11:40:51 -0500
Subject: Use of forall as a sigil
In-Reply-To: <LNXP265MB141927F470139DD3AE7B6B08A5FD0@LNXP265MB1419.GBRP265.PROD.OUTLOOK.COM>
References: <LNXP265MB141927F470139DD3AE7B6B08A5FD0@LNXP265MB1419.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <e1ef6313-e5f3-7d8e-c810-1b6331587718@obsidian.systems>

I have thought about this too, and don't believe it has been widely 
discussed.

- We are already getting `forall {a}.`, so it fits nicely with that.

- However, it would have to be `forall @a ->`, because `forall a.` is 
already an invisible quantification, unless one wants to just change the 
meaning of `forall a.`!

John

On 11/22/20 6:23 AM, Andrey Mokhov wrote:
> Hi Richard,
>
>> In the end, I've never loved the forall ... -> syntax, but I've never seen
>> anything better.
> What about the forall @a. syntax?
>
> For example:
>
>    sizeOf :: forall @a. Sized a => Int
>
> We already use @ to explicitly specify types, so it seems natural mark type parameters that must be explicitly specified with @ too.
>
> Here's how one would read it: "for all explicitly specified a, ..."
>
> Apologies if this has been discussed and I missed it. It doesn't seem to be mentioned in the Alternatives section of the proposal but perhaps it will just never work for some reason.
>
> Cheers,
> Andrey
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From andrey.mokhov at newcastle.ac.uk  Sun Nov 22 20:03:47 2020
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Sun, 22 Nov 2020 20:03:47 +0000
Subject: Use of forall as a sigil
In-Reply-To: <e1ef6313-e5f3-7d8e-c810-1b6331587718@obsidian.systems>
References: <LNXP265MB141927F470139DD3AE7B6B08A5FD0@LNXP265MB1419.GBRP265.PROD.OUTLOOK.COM>
 <e1ef6313-e5f3-7d8e-c810-1b6331587718@obsidian.systems>
Message-ID: <LNXP265MB1419C0E65001F9B2F8364FDEA5FD0@LNXP265MB1419.GBRP265.PROD.OUTLOOK.COM>

Hi John,

> - We are already getting `forall {a}.`, so it fits nicely with that.

Interesting, I wasn't aware of this. Could you point me to the relevant proposal?

> - However, it would have to be `forall @a ->`, 

Oh, that seems even worse than `forall a ->` to me.

> because `forall a.` is already an invisible quantification,
> unless one wants to just change the meaning of `forall a.`!

I'm confused. I wasn't suggesting to change the meaning of `forall a.`.

My suggestion was pretty incremental:

* `forall a.` stays as is: it allows for both invisible and visible type arguments.
* `forall @a.` requires a visible type argument.

Cheers,
Andrey

-----Original Message-----
From: John Ericson [mailto:john.ericson at obsidian.systems] 
Sent: 22 November 2020 16:41
To: Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Richard Eisenberg <rae at richarde.dev>
Cc: ghc-devs at haskell.org
Subject: Re: Use of forall as a sigil


I have thought about this too, and don't believe it has been widely
discussed.

- We are already getting `forall {a}.`, so it fits nicely with that.

- However, it would have to be `forall @a ->`, because `forall a.` is
already an invisible quantification, unless one wants to just change the
meaning of `forall a.`!

John


From rae at richarde.dev  Mon Nov 23 03:24:21 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 23 Nov 2020 03:24:21 +0000
Subject: Use of forall as a sigil
In-Reply-To: <LNXP265MB1419C0E65001F9B2F8364FDEA5FD0@LNXP265MB1419.GBRP265.PROD.OUTLOOK.COM>
References: <LNXP265MB141927F470139DD3AE7B6B08A5FD0@LNXP265MB1419.GBRP265.PROD.OUTLOOK.COM>
 <e1ef6313-e5f3-7d8e-c810-1b6331587718@obsidian.systems>
 <LNXP265MB1419C0E65001F9B2F8364FDEA5FD0@LNXP265MB1419.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <010f0175f32185a6-a600d26c-29ab-49a0-a7df-1a2919ec4ed5-000000@us-east-2.amazonses.com>

For me, the problem with `forall @a .` is that it seems to go in the wrong direction: parameters declared with @ must not have @ when passed, and parameters declared without @ must have a @ if the parameter is passed explicitly.

However, if we say that @ makes a thing that is normally implicit explicit, maybe it works?

Richard

> On Nov 22, 2020, at 3:03 PM, Andrey Mokhov <andrey.mokhov at newcastle.ac.uk> wrote:
> 
> Hi John,
> 
>> - We are already getting `forall {a}.`, so it fits nicely with that.
> 
> Interesting, I wasn't aware of this. Could you point me to the relevant proposal?
> 
>> - However, it would have to be `forall @a ->`, 
> 
> Oh, that seems even worse than `forall a ->` to me.
> 
>> because `forall a.` is already an invisible quantification,
>> unless one wants to just change the meaning of `forall a.`!
> 
> I'm confused. I wasn't suggesting to change the meaning of `forall a.`.
> 
> My suggestion was pretty incremental:
> 
> * `forall a.` stays as is: it allows for both invisible and visible type arguments.
> * `forall @a.` requires a visible type argument.
> 
> Cheers,
> Andrey
> 
> -----Original Message-----
> From: John Ericson [mailto:john.ericson at obsidian.systems] 
> Sent: 22 November 2020 16:41
> To: Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Richard Eisenberg <rae at richarde.dev>
> Cc: ghc-devs at haskell.org
> Subject: Re: Use of forall as a sigil
> 
> 
> I have thought about this too, and don't believe it has been widely
> discussed.
> 
> - We are already getting `forall {a}.`, so it fits nicely with that.
> 
> - However, it would have to be `forall @a ->`, because `forall a.` is
> already an invisible quantification, unless one wants to just change the
> meaning of `forall a.`!
> 
> John
> 


From rae at richarde.dev  Mon Nov 23 03:48:22 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 23 Nov 2020 03:48:22 +0000
Subject: Questions about System F and data types
In-Reply-To: <412bc033-6bae-e105-c819-b825a4434e12@vanbruegge.de>
References: <412bc033-6bae-e105-c819-b825a4434e12@vanbruegge.de>
Message-ID: <010f0175f33781e8-6bada229-fdb1-46fe-9fb6-029a6178f470-000000@us-east-2.amazonses.com>



> On Nov 22, 2020, at 6:49 AM, Jan van Brügge <jan at vanbruegge.de> wrote:
> To better understand PL papers, especially those involving System Fc and its extensions, I started to write a formal proof of type safety including alpha-equivalence. Currently I have a complete proof for System F <https://github.com/jvanbruegge/isabelle-lambda-calculus> (without coercions and data types yet). I mainly used the System Fc paper <https://www.microsoft.com/en-us/research/wp-content/uploads/2007/01/tldi22-sulzmann-with-appendix.pdf> as reference, ignoring all the parts about coercions.
> 
> 

I'm not an author of that paper (and, somewhat surprisingly, have never taken a very deep dive into it). But I can try to answer your questions.
> 1. In the Fc paper, the rule `AppT` has a judgement delta as assumption, which does not exist. I assumed the `ty` judgement was meant there by looking at the arguments. Is this correct?
> 
> 

In the grammar figure (Fig. 1), we see that \delta is either TY or CO. Both the TY and CO judgments are included in Fig. 2. So, in effect, you're assumption is correct, but the rule covers also coercion application, as well as type application.

> 2. In the `Abs` rule, the type of the variable is required to be valid and of kind star by the judgement `ty`. In the `Let` rule, this assumption is missing. I tried it like that, but was not able to complete the proofs. Is such an assumption missing there or should I be able to proof it without?
> 
> 

I don't think Let is missing a premise. However, I do think the paper should explicitly state the following lemma (which I believe is true of this system):

Lemma (Regularity). If G |e- e : s, then G |TY- s : *.

(You might also need to assert that the size of the resulting derivation is strictly smaller than the input -- not sure if your application would need that to power an induction hypothesis.) With that lemma, you could essentially recreate the premise you were hoping to spot on Let.
> 3. In the Fc paper, the types and kinds of datatype declarations are added to the context with a separate judgement that interprets the datatype declarations. In the System Fc pro paper <https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/p53-yorgey.pdf?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fext-f%2Fpromotion.pdf> (from what I can tell) those types and kinds are assumed to be already part of the initial context. At the moment I prove progress against the empty context, so I guess I would have to relax that to an initial context that only contains types and kinds of type constants and nothing else. Is that correct? What is here the "best practice" in terms of PL research?
> 
> 

The important thing in a progress proof is that there are no term variables in the context. But types and kinds are all OK. Different authors take different approaches. Some authors define what's called a *signatures* (frequently written with a \Sigma) that contains type/kind definitions (only). All judgments are then parameterized over both a signature and a typing context. Other authors allow the context to contain all kinds of assumptions, but then state that the context in the progress theorem has no term-variable bindings. I don't think one approach is necessarily better than another.

I would encourage you to take a look also at the proof of type safety in https://richarde.dev/papers/2016/coercible-jfp/coercible-jfp.pdf. That paper is concerned with roles (which, presumably, you are not), but the proof is (to my knowledge) the most careful proof presented about System FC. Other papers since have mechanized parts of the proof, but those work with a variant of FC that is dependently typed.

I hope this helps!
Richard
> Thank you all
> Jan
> _______________________________________________
> 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/20201123/6234c698/attachment.html>

From rae at richarde.dev  Mon Nov 23 03:54:46 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 23 Nov 2020 03:54:46 +0000
Subject: Adding a way to reduce type families in type errors
In-Reply-To: <CAJjQ6oMxZV79DsKuuv-XfPLYe3Qcc2EFC7TTXTums3nqxy0hOQ@mail.gmail.com>
References: <CAJjQ6oMxZV79DsKuuv-XfPLYe3Qcc2EFC7TTXTums3nqxy0hOQ@mail.gmail.com>
Message-ID: <010f0175f33d5e0b-7ac7f617-b444-4b7c-b8eb-64cd53c71c4c-000000@us-east-2.amazonses.com>



> On Nov 21, 2020, at 10:38 PM, Jakob Brünker <jakob.bruenker at gmail.com> wrote:
> 
> Three questions:
>  - Is there already a way to do this that I'm missing?

Not that I'm aware of. GHC sometimes expands type families and sometimes doesn't. The general philosophy has been that expanding type families is usually good and expanding type synonyms is usually bad. But it wouldn't surprise me in the slightest if GHC is inconsistent about this.

>  - Are there reasons for why this would be a bad idea?

If we did it unconditionally, I imagine some error messages would get worse. Adding a new flag would make the interface to GHC more complex, but perhaps it's worth it.

>  - Would a proposal be necessary for this?

For me, it would depend on the invasiveness of the change; however, making type families expand is already what we try to do, so probably not.

But before blazing ahead, you may want to know that my !4149 already prints what you want. Testing your example yields

Scratch.hs:32:52: error:
    • Couldn't match kind ‘()’ with ‘Maybe String’
      Expected kind ‘Maybe (Foo Int)’, but ‘'()’ has kind ‘()’
    • In the type ‘'()’
      In the type family declaration for ‘Bar’

which I imagine is acceptable.

Richard



> 
> Thanks,
> Jakob
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From jakob.bruenker at gmail.com  Mon Nov 23 04:01:11 2020
From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=)
Date: Mon, 23 Nov 2020 05:01:11 +0100
Subject: Adding a way to reduce type families in type errors
In-Reply-To: <010f0175f33d5e0b-7ac7f617-b444-4b7c-b8eb-64cd53c71c4c-000000@us-east-2.amazonses.com>
References: <CAJjQ6oMxZV79DsKuuv-XfPLYe3Qcc2EFC7TTXTums3nqxy0hOQ@mail.gmail.com>
 <010f0175f33d5e0b-7ac7f617-b444-4b7c-b8eb-64cd53c71c4c-000000@us-east-2.amazonses.com>
Message-ID: <CAJjQ6oNX8D4FiSqANJo8wFG1sQ8A_uiNwDZoDZqNnEf2aQ4U0w@mail.gmail.com>

Ah, the result produced by !4149 does indeed look good. Thanks!

Jakob

On Mon, Nov 23, 2020 at 4:54 AM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> > On Nov 21, 2020, at 10:38 PM, Jakob Brünker <jakob.bruenker at gmail.com>
> wrote:
> >
> > Three questions:
> >  - Is there already a way to do this that I'm missing?
>
> Not that I'm aware of. GHC sometimes expands type families and sometimes
> doesn't. The general philosophy has been that expanding type families is
> usually good and expanding type synonyms is usually bad. But it wouldn't
> surprise me in the slightest if GHC is inconsistent about this.
>
> >  - Are there reasons for why this would be a bad idea?
>
> If we did it unconditionally, I imagine some error messages would get
> worse. Adding a new flag would make the interface to GHC more complex, but
> perhaps it's worth it.
>
> >  - Would a proposal be necessary for this?
>
> For me, it would depend on the invasiveness of the change; however, making
> type families expand is already what we try to do, so probably not.
>
> But before blazing ahead, you may want to know that my !4149 already
> prints what you want. Testing your example yields
>
> Scratch.hs:32:52: error:
>     • Couldn't match kind ‘()’ with ‘Maybe String’
>       Expected kind ‘Maybe (Foo Int)’, but ‘'()’ has kind ‘()’
>     • In the type ‘'()’
>       In the type family declaration for ‘Bar’
>
> which I imagine is acceptable.
>
> Richard
>
>
>
> >
> > Thanks,
> > Jakob
> > _______________________________________________
> > 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/20201123/505c91bf/attachment.html>

From george.colpitts at gmail.com  Tue Nov 24 00:12:51 2020
From: george.colpitts at gmail.com (George Colpitts)
Date: Mon, 23 Nov 2020 20:12:51 -0400
Subject: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released
In-Reply-To: <873631g1e2.fsf@smart-cactus.org>
References: <873631g1e2.fsf@smart-cactus.org>
Message-ID: <CAB-d4A6PvUzMLC1b2_GO0oJ4XJfWKeL9T+rz5pOhzo-_ePEkrQ@mail.gmail.com>

Hi Ben,

What are the current plans / schedule for 9.0.1?

Thanks
George


On Mon, Sep 28, 2020 at 4:14 PM Ben Gamari <ben at well-typed.com> wrote:

> Hello all,
>
> The GHC team is very pleased to announce the availability of the first
> alpha release in the GHC 9.0 series. Source and binary distributions are
> available at the usual place:
>
>     https://downloads.haskell.org/ghc/9.0.1-alpha1/
>
> This first alpha comes quite a bit later than expected. However, we have
> done a significant amount of testing on this pre-release and therefore
> hope to be able to move forward quickly with a release candidate next
> week and with a final release in mid-October.
>
> GHC 9.0.1 will bring a number of new features:
>
>  * A first cut of the new LinearTypes language extension [1], allowing
>    use of linear function syntax and linear record fields.
>
>  * A new bignum library (ghc-bignum), allowing GHC to be more easily
>    used with integer libraries other than GMP.
>
>  * Improvements in code generation, resulting in considerable
>    performance improvements in some programs.
>
>  * Improvements in pattern-match checking, allowing more precise
>    detection of redundant cases and reduced compilation time.
>
>  * Implementation of the "simplified subsumption" proposal [2]
>    simplifying the type system and paving the way for QuickLook
>    impredicativity in GHC 9.2.
>
>  * Implementation of the QualifiedDo extension [3], allowing more
>    convenient overloading of `do` syntax.
>
>  * Improvements in compilation time.
>
> And many more. See the release notes [4] for a full accounting of the
> changes in this release.
>
> Do note that there are a few things that we expect will change before
> the final release:
>
>  * We expect to sort out a notarization workflow for Apple Darwin,
>    allowing our binary distributions to be used on macOS Catalina
>    without hassle.
>
>    Until this has been sorted out Catalina users can exempt the
>    current macOS binary distribution from the notarization requirement
>    themselves by running `xattr -cr .` on the unpacked tree before
>    running `make install`.
>
>  * We will likely transition the Alpine binary distribution to be fully
>    statically-linked, providing a convenient, distribution-independent
>    packaging option for Linux users.
>
>  * We will be merging a robust solution for #17760 which will introduce
>    a new primitive, `keepAlive#`, to the `base` library, subsuming
>    most uses of `touch#`.
>
> As always, do test this release and open tickets for whatever issues you
> encounter. To help with this, we will be publishing a blog post
> describing use of our new `head.hackage` infrastructure to ease testing
> of larger projects with Hackage dependencies later this week.
>
> Cheers,
>
> - Ben
>
>
> [1]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
> [2]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
> [3]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst
> [4]
> https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201123/93cb0001/attachment.html>

From ben at well-typed.com  Tue Nov 24 00:22:16 2020
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 23 Nov 2020 19:22:16 -0500
Subject: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released
In-Reply-To: <CAB-d4A6PvUzMLC1b2_GO0oJ4XJfWKeL9T+rz5pOhzo-_ePEkrQ@mail.gmail.com>
References: <873631g1e2.fsf@smart-cactus.org>
 <CAB-d4A6PvUzMLC1b2_GO0oJ4XJfWKeL9T+rz5pOhzo-_ePEkrQ@mail.gmail.com>
Message-ID: <87v9dv38p6.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> Hi Ben,
>
> What are the current plans / schedule for 9.0.1?
>
Hi George,

At the moment things are blocked on a solution to #17760, which I am
currently in the process of working through. There have been several
false-starts on this ticket and while the solution we are ending up with
is indeed a compromise (in both performance impact and convenience), I
am fairly convinced it is the best we can do.

I am waiting for a version of the patch to validate as we speak. As soon
as it (and a few other relevant patches) have been backported I will
move ahead with cutting the release candidate. I hope this can happen by
the end of the week.

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/20201123/05e63f02/attachment.sig>

From simonpj at microsoft.com  Tue Nov 24 08:27:37 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 24 Nov 2020 08:27:37 +0000
Subject: HEAD user manual
Message-ID: <PR3PR83MB04752E363C841ECC437A8E7DADFB0@PR3PR83MB0475.EURPRD83.prod.outlook.com>

Where can I find the GHC user manual for HEAD these days?
I tried https://ghc.gitlab.haskell.org/ghc/doc/, but that takes me to 8.11.
The user documentation page https://gitlab.haskell.org/ghc/ghc/-/wikis/ghc-users-guide#ghc-users-documentation has the same link.
Thanks
Simon

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

From ben at smart-cactus.org  Tue Nov 24 16:11:22 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 24 Nov 2020 11:11:22 -0500
Subject: HEAD user manual
In-Reply-To: <PR3PR83MB04752E363C841ECC437A8E7DADFB0@PR3PR83MB0475.EURPRD83.prod.outlook.com>
References: <PR3PR83MB04752E363C841ECC437A8E7DADFB0@PR3PR83MB0475.EURPRD83.prod.outlook.com>
Message-ID: <87sg8y3fbs.fsf@smart-cactus.org>

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

> Where can I find the GHC user manual for HEAD these days?
> I tried https://ghc.gitlab.haskell.org/ghc/doc/, but that takes me to 8.11.
> The user documentation page
> https://gitlab.haskell.org/ghc/ghc/-/wikis/ghc-users-guide#ghc-users-documentation
> has the same link.

That is the correct link but sadly it hasn't been updated in quite a
while due to #18973 (which is in turn blocked on #18669). I'm going to
try to get to this one keepAlive# is done.

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/20201124/a3ede47a/attachment.sig>

From jan at vanbruegge.de  Tue Nov 24 20:57:38 2020
From: jan at vanbruegge.de (=?UTF-8?Q?Jan_van_Br=c3=bcgge?=)
Date: Tue, 24 Nov 2020 21:57:38 +0100
Subject: Questions about System F and data types
In-Reply-To: <010f0175f33781e8-6bada229-fdb1-46fe-9fb6-029a6178f470-000000@us-east-2.amazonses.com>
References: <412bc033-6bae-e105-c819-b825a4434e12@vanbruegge.de>
 <010f0175f33781e8-6bada229-fdb1-46fe-9fb6-029a6178f470-000000@us-east-2.amazonses.com>
Message-ID: <5629257c-4f09-9920-a921-54a6136fe805@vanbruegge.de>

Thank you for those answers! Back to proving again :)

On 23.11.20 04:48, Richard Eisenberg wrote:
>
>
>> On Nov 22, 2020, at 6:49 AM, Jan van Brügge <jan at vanbruegge.de
>> <mailto:jan at vanbruegge.de>> wrote:
>>
>> To better understand PL papers, especially those involving System Fc
>> and its extensions, I started to write a formal proof of type safety
>> including alpha-equivalence. Currently I have a complete proof for
>> System F <https://github.com/jvanbruegge/isabelle-lambda-calculus>
>> (without coercions and data types yet). I mainly used the System Fc
>> paper
>> <https://www.microsoft.com/en-us/research/wp-content/uploads/2007/01/tldi22-sulzmann-with-appendix.pdf>
>> as reference, ignoring all the parts about coercions.
>>
>>
>
> I'm not an author of that paper (and, somewhat surprisingly, have
> never taken a very deep dive into it). But I can try to answer your
> questions.
>>
>> 1. In the Fc paper, the rule `AppT` has a judgement delta as
>> assumption, which does not exist. I assumed the `ty` judgement was
>> meant there by looking at the arguments. Is this correct?
>>
>>
>
> In the grammar figure (Fig. 1), we see that \delta is either TY or CO.
> Both the TY and CO judgments are included in Fig. 2. So, in effect,
> you're assumption is correct, but the rule covers also coercion
> application, as well as type application.
>
>> 2. In the `Abs` rule, the type of the variable is required to be
>> valid and of kind star by the judgement `ty`. In the `Let` rule, this
>> assumption is missing. I tried it like that, but was not able to
>> complete the proofs. Is such an assumption missing there or should I
>> be able to proof it without?
>>
>>
>
> I don't think Let is missing a premise. However, I do think the paper
> should explicitly state the following lemma (which I believe is true
> of this system):
>
> Lemma (Regularity). If G |e- e : s, then G |TY- s : *.
>
> (You might also need to assert that the size of the resulting
> derivation is strictly smaller than the input -- not sure if your
> application would need that to power an induction hypothesis.) With
> that lemma, you could essentially recreate the premise you were hoping
> to spot on Let.
>>
>> 3. In the Fc paper, the types and kinds of datatype declarations are
>> added to the context with a separate judgement that interprets the
>> datatype declarations. In the System Fc pro paper
>> <https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/p53-yorgey.pdf?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fext-f%2Fpromotion.pdf>
>> (from what I can tell) those types and kinds are assumed to be
>> already part of the initial context. At the moment I prove progress
>> against the empty context, so I guess I would have to relax that to
>> an initial context that only contains types and kinds of type
>> constants and nothing else. Is that correct? What is here the "best
>> practice" in terms of PL research?
>>
>>
>
> The important thing in a progress proof is that there are no term
> variables in the context. But types and kinds are all OK. Different
> authors take different approaches. Some authors define what's called a
> *signatures* (frequently written with a \Sigma) that contains
> type/kind definitions (only). All judgments are then parameterized
> over both a signature and a typing context. Other authors allow the
> context to contain all kinds of assumptions, but then state that the
> context in the progress theorem has no term-variable bindings. I don't
> think one approach is necessarily better than another.
>
> I would encourage you to take a look also at the proof of type safety
> in https://richarde.dev/papers/2016/coercible-jfp/coercible-jfp.pdf
> <https://richarde.dev/papers/2016/coercible-jfp/coercible-jfp.pdf>.
> That paper is concerned with roles (which, presumably, you are not),
> but the proof is (to my knowledge) the most careful proof presented
> about System FC. Other papers since have mechanized parts of the
> proof, but those work with a variant of FC that is dependently typed.
>
> I hope this helps!
> Richard
>>
>> Thank you all
>> Jan
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201124/2ad96166/attachment.html>

From rsx at bluewin.ch  Wed Nov 25 09:33:04 2020
From: rsx at bluewin.ch (Roland Senn)
Date: Wed, 25 Nov 2020 10:33:04 +0100
Subject: Hadrian: Error "cannot find -lHSrts-1.0_thr_l" when linking ghc
 executable.
Message-ID: <cfec4c2448da393935ba9d31c007a7872098463b.camel@bluewin.ch>

Hi there!

I have two GHC trees. One is called ghcdebug and is a little bit
outdated (16. September 2020). In this tree, I can work normally:
Change code, compile and run the resulting GHC compiler. 

The second tree is up-to-date! Compiling works fine, however the linker
steps for the ghc executable fails. When I restart the failing link
step, I get the following error:

$ hadrian/build --flavour=devel2 --freeze1 -j2 stage2:exe:ghc-bin
Up to date
| Run Ghc LinkHs Stage1: _build/stage1/ghc/build/c/hschooks.o (and 7
more) => _build/stage1/bin/ghc
/usr/bin/ld.gold: error: cannot find -lHSrts-1.0_thr_l
_build/stage1/ghc/build/GHCi/Leak.o(.text+0xd5): error: undefined
reference to 'stg_upd_frame_info'
_build/stage1/ghc/build/GHCi/Leak.o(.text+0x1c2): error: undefined
reference to 'stg_upd_frame_info'
_build/stage1/ghc/build/GHCi/Leak.o(.text+0x1e6): error: undefined
reference to 'stg_ap_ppp_info'
              ...  and many many more lines with "error: undefined
reference to ..." 

I get the same error when I use a freshly cloned ghc tree. I also get
the error independently of the GHC version used to compile (8.8.3 or
8.10.2). I didn't modify any settings files.

I do:  
   hadrian/build clean
   hadrian/build --flavour=devel2 -j2

I'm using a normal x68_64 box with plain vanilla Linux Debian 10. No
Docker and no Nix.

The directory _build/stage/rts/build contains:

roland at goms:~/Projekte/ghc$ ls -all _build/stage1/rts/build/
insgesamt 19396
drwxr-xr-x 5 roland roland     4096 Nov 24 17:58 .
drwxr-xr-x 3 roland roland     4096 Nov 24 17:56 ..
drwxr-xr-x 2 roland roland     4096 Nov 24 17:56 autogen
drwxr-xr-x 7 roland roland    12288 Nov 24 17:58 c
drwxr-xr-x 2 roland roland     4096 Nov 24 17:58 cmm
-rw-r--r-- 1 roland roland    31349 Nov 24 17:58 DerivedConstants.h
-rw-r--r-- 1 roland roland    13764 Nov 24 17:57 ffi.h
-rw-r--r-- 1 roland roland     4343 Nov 24 17:57 ffitarget.h
-rw-r--r-- 1 roland roland    15128 Nov 24 17:58 ghcautoconf.h
-rw-r--r-- 1 roland roland      618 Nov 24 17:58 ghcplatform.h
-rw-r--r-- 1 roland roland      732 Nov 24 17:58 ghcversion.h
-rw-r--r-- 1 roland roland    82486 Nov 24 17:57 libCffi.a
lrwxrwxrwx 1 roland roland        9 Nov 24 17:57 libCffi_thr.a ->
libCffi.a
-rw-r--r-- 1 roland roland  9166966 Nov 24 17:58 libHSrts-1.0.a
-rw-r--r-- 1 roland roland 10490730 Nov 24 17:58 libHSrts-1.0_thr.a

Any ideas what's wrong or how to fix?

Many thanks and Cheers,
   Roland


From sgraf1337 at gmail.com  Wed Nov 25 09:38:33 2020
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Wed, 25 Nov 2020 10:38:33 +0100
Subject: Hadrian: Error "cannot find -lHSrts-1.0_thr_l" when linking ghc
 executable.
In-Reply-To: <cfec4c2448da393935ba9d31c007a7872098463b.camel@bluewin.ch>
References: <cfec4c2448da393935ba9d31c007a7872098463b.camel@bluewin.ch>
Message-ID: <CAAS+=P8VSy0Rjyy15oZEpNnX77pOg6FJdhk5bTJfJMfEq0BHzw@mail.gmail.com>

Hi Roland,

Since you mention an RTS variant with an _l suffix (for eventlog), I
suspect that you may have to (reboot? and) reconfigure after
https://gitlab.haskell.org/ghc/ghc/-/issues/18948 and
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4448.

Does that help?

Cheers,
Sebastian

Am Mi., 25. Nov. 2020 um 10:33 Uhr schrieb Roland Senn <rsx at bluewin.ch>:

> Hi there!
>
> I have two GHC trees. One is called ghcdebug and is a little bit
> outdated (16. September 2020). In this tree, I can work normally:
> Change code, compile and run the resulting GHC compiler.
>
> The second tree is up-to-date! Compiling works fine, however the linker
> steps for the ghc executable fails. When I restart the failing link
> step, I get the following error:
>
> $ hadrian/build --flavour=devel2 --freeze1 -j2 stage2:exe:ghc-bin
> Up to date
> | Run Ghc LinkHs Stage1: _build/stage1/ghc/build/c/hschooks.o (and 7
> more) => _build/stage1/bin/ghc
> /usr/bin/ld.gold: error: cannot find -lHSrts-1.0_thr_l
> _build/stage1/ghc/build/GHCi/Leak.o(.text+0xd5): error: undefined
> reference to 'stg_upd_frame_info'
> _build/stage1/ghc/build/GHCi/Leak.o(.text+0x1c2): error: undefined
> reference to 'stg_upd_frame_info'
> _build/stage1/ghc/build/GHCi/Leak.o(.text+0x1e6): error: undefined
> reference to 'stg_ap_ppp_info'
>               ...  and many many more lines with "error: undefined
> reference to ..."
>
> I get the same error when I use a freshly cloned ghc tree. I also get
> the error independently of the GHC version used to compile (8.8.3 or
> 8.10.2). I didn't modify any settings files.
>
> I do:
>    hadrian/build clean
>    hadrian/build --flavour=devel2 -j2
>
> I'm using a normal x68_64 box with plain vanilla Linux Debian 10. No
> Docker and no Nix.
>
> The directory _build/stage/rts/build contains:
>
> roland at goms:~/Projekte/ghc$ ls -all _build/stage1/rts/build/
> insgesamt 19396
> drwxr-xr-x 5 roland roland     4096 Nov 24 17:58 .
> drwxr-xr-x 3 roland roland     4096 Nov 24 17:56 ..
> drwxr-xr-x 2 roland roland     4096 Nov 24 17:56 autogen
> drwxr-xr-x 7 roland roland    12288 Nov 24 17:58 c
> drwxr-xr-x 2 roland roland     4096 Nov 24 17:58 cmm
> -rw-r--r-- 1 roland roland    31349 Nov 24 17:58 DerivedConstants.h
> -rw-r--r-- 1 roland roland    13764 Nov 24 17:57 ffi.h
> -rw-r--r-- 1 roland roland     4343 Nov 24 17:57 ffitarget.h
> -rw-r--r-- 1 roland roland    15128 Nov 24 17:58 ghcautoconf.h
> -rw-r--r-- 1 roland roland      618 Nov 24 17:58 ghcplatform.h
> -rw-r--r-- 1 roland roland      732 Nov 24 17:58 ghcversion.h
> -rw-r--r-- 1 roland roland    82486 Nov 24 17:57 libCffi.a
> lrwxrwxrwx 1 roland roland        9 Nov 24 17:57 libCffi_thr.a ->
> libCffi.a
> -rw-r--r-- 1 roland roland  9166966 Nov 24 17:58 libHSrts-1.0.a
> -rw-r--r-- 1 roland roland 10490730 Nov 24 17:58 libHSrts-1.0_thr.a
>
> Any ideas what's wrong or how to fix?
>
> Many thanks and Cheers,
>    Roland
>
> _______________________________________________
> 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/20201125/c0091758/attachment.html>

From sgraf1337 at gmail.com  Wed Nov 25 09:40:13 2020
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Wed, 25 Nov 2020 10:40:13 +0100
Subject: Hadrian: Error "cannot find -lHSrts-1.0_thr_l" when linking ghc
 executable.
In-Reply-To: <CAAS+=P8VSy0Rjyy15oZEpNnX77pOg6FJdhk5bTJfJMfEq0BHzw@mail.gmail.com>
References: <cfec4c2448da393935ba9d31c007a7872098463b.camel@bluewin.ch>
 <CAAS+=P8VSy0Rjyy15oZEpNnX77pOg6FJdhk5bTJfJMfEq0BHzw@mail.gmail.com>
Message-ID: <CAAS+=P96ex5jXu=FOrLu40Pd5pd+YtTmCuRuWE=pLxZxQQNDxQ@mail.gmail.com>

Oh, nevermind. See the comments on
https://gitlab.haskell.org/ghc/ghc/-/commit/fc644b1a643128041cfec25db84e417851e28bab.
Apparently, master really is broken in devel2 flavour!

Am Mi., 25. Nov. 2020 um 10:38 Uhr schrieb Sebastian Graf <
sgraf1337 at gmail.com>:

> Hi Roland,
>
> Since you mention an RTS variant with an _l suffix (for eventlog), I
> suspect that you may have to (reboot? and) reconfigure after
> https://gitlab.haskell.org/ghc/ghc/-/issues/18948 and
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4448.
>
> Does that help?
>
> Cheers,
> Sebastian
>
> Am Mi., 25. Nov. 2020 um 10:33 Uhr schrieb Roland Senn <rsx at bluewin.ch>:
>
>> Hi there!
>>
>> I have two GHC trees. One is called ghcdebug and is a little bit
>> outdated (16. September 2020). In this tree, I can work normally:
>> Change code, compile and run the resulting GHC compiler.
>>
>> The second tree is up-to-date! Compiling works fine, however the linker
>> steps for the ghc executable fails. When I restart the failing link
>> step, I get the following error:
>>
>> $ hadrian/build --flavour=devel2 --freeze1 -j2 stage2:exe:ghc-bin
>> Up to date
>> | Run Ghc LinkHs Stage1: _build/stage1/ghc/build/c/hschooks.o (and 7
>> more) => _build/stage1/bin/ghc
>> /usr/bin/ld.gold: error: cannot find -lHSrts-1.0_thr_l
>> _build/stage1/ghc/build/GHCi/Leak.o(.text+0xd5): error: undefined
>> reference to 'stg_upd_frame_info'
>> _build/stage1/ghc/build/GHCi/Leak.o(.text+0x1c2): error: undefined
>> reference to 'stg_upd_frame_info'
>> _build/stage1/ghc/build/GHCi/Leak.o(.text+0x1e6): error: undefined
>> reference to 'stg_ap_ppp_info'
>>               ...  and many many more lines with "error: undefined
>> reference to ..."
>>
>> I get the same error when I use a freshly cloned ghc tree. I also get
>> the error independently of the GHC version used to compile (8.8.3 or
>> 8.10.2). I didn't modify any settings files.
>>
>> I do:
>>    hadrian/build clean
>>    hadrian/build --flavour=devel2 -j2
>>
>> I'm using a normal x68_64 box with plain vanilla Linux Debian 10. No
>> Docker and no Nix.
>>
>> The directory _build/stage/rts/build contains:
>>
>> roland at goms:~/Projekte/ghc$ ls -all _build/stage1/rts/build/
>> insgesamt 19396
>> drwxr-xr-x 5 roland roland     4096 Nov 24 17:58 .
>> drwxr-xr-x 3 roland roland     4096 Nov 24 17:56 ..
>> drwxr-xr-x 2 roland roland     4096 Nov 24 17:56 autogen
>> drwxr-xr-x 7 roland roland    12288 Nov 24 17:58 c
>> drwxr-xr-x 2 roland roland     4096 Nov 24 17:58 cmm
>> -rw-r--r-- 1 roland roland    31349 Nov 24 17:58 DerivedConstants.h
>> -rw-r--r-- 1 roland roland    13764 Nov 24 17:57 ffi.h
>> -rw-r--r-- 1 roland roland     4343 Nov 24 17:57 ffitarget.h
>> -rw-r--r-- 1 roland roland    15128 Nov 24 17:58 ghcautoconf.h
>> -rw-r--r-- 1 roland roland      618 Nov 24 17:58 ghcplatform.h
>> -rw-r--r-- 1 roland roland      732 Nov 24 17:58 ghcversion.h
>> -rw-r--r-- 1 roland roland    82486 Nov 24 17:57 libCffi.a
>> lrwxrwxrwx 1 roland roland        9 Nov 24 17:57 libCffi_thr.a ->
>> libCffi.a
>> -rw-r--r-- 1 roland roland  9166966 Nov 24 17:58 libHSrts-1.0.a
>> -rw-r--r-- 1 roland roland 10490730 Nov 24 17:58 libHSrts-1.0_thr.a
>>
>> Any ideas what's wrong or how to fix?
>>
>> Many thanks and Cheers,
>>    Roland
>>
>> _______________________________________________
>> 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/20201125/f5ef01eb/attachment.html>

From rsx at bluewin.ch  Wed Nov 25 10:21:13 2020
From: rsx at bluewin.ch (Roland Senn)
Date: Wed, 25 Nov 2020 11:21:13 +0100
Subject: Hadrian: Error "cannot find -lHSrts-1.0_thr_l" when linking ghc
 executable.
In-Reply-To: <CAAS+=P96ex5jXu=FOrLu40Pd5pd+YtTmCuRuWE=pLxZxQQNDxQ@mail.gmail.com>
References: <cfec4c2448da393935ba9d31c007a7872098463b.camel@bluewin.ch>
 <CAAS+=P8VSy0Rjyy15oZEpNnX77pOg6FJdhk5bTJfJMfEq0BHzw@mail.gmail.com>
 <CAAS+=P96ex5jXu=FOrLu40Pd5pd+YtTmCuRuWE=pLxZxQQNDxQ@mail.gmail.com>
Message-ID: <1ab04a7d862c57a1bbff04e49a0fa7ef527bf6d9.camel@bluewin.ch>

Yes, this helped! Many many thanks to Sebastian!!
Regards   Roland
Am Mittwoch, den 25.11.2020, 10:40 +0100 schrieb Sebastian Graf:
> Oh, nevermind. See the comments on 
> https://gitlab.haskell.org/ghc/ghc/-/commit/fc644b1a643128041cfec25db84e417851e28bab
> . Apparently, master really is broken in devel2 flavour!
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201125/9457e4f6/attachment.html>

From christiaan.baaij at gmail.com  Mon Nov 30 16:41:54 2020
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Mon, 30 Nov 2020 17:41:54 +0100
Subject: PSA: type checker plugins to be affected by upcoming changes to
 GHC
In-Reply-To: <010f0175e72ec24f-c12ce71e-4192-4f37-befa-afb1a9b409d5-000000@us-east-2.amazonses.com>
References: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
 <CABzw7bU100ZYogrQzqMav=DYJdtKwKaVcLkq2uhKqeeDUk2eYQ@mail.gmail.com>
 <CAGK9nuqiQRhvxo=FKup1iVK+cimWvCfJ778TjwuGf8TGuCsHWw@mail.gmail.com>
 <010f0175e72ec24f-c12ce71e-4192-4f37-befa-afb1a9b409d5-000000@us-east-2.amazonses.com>
Message-ID: <CABzw7bUA40dW8m6G0mWQhF61TdsO5coT_CvKhYbVsqFkT45u-A@mail.gmail.com>

Richard, I just watched your talk about simplifying the constraint solver:
https://www.youtube.com/watch?v=flwz6V5Ps8w
and then realised that no flattening at all means also no flattening of
[W]anteds.

Now, let's say I have a type family called "Magic" for which I want to
write a constraint solver plugin; and some type family "Foo" and "Bar"
And then lets say we start out with an original [W]anted: Foo (Magic 8) ~
Bar 42

Then if I understand flattening correctly, that would get flattened to:
[w] Magic 8 ~ fmv1
[w] fmv1 ~ 42
[w] Foo fmv1 ~ fmv2
[w] fmv2 ~ Bar fmv1

Correct?

So currently, with flattened wanted, all a constraint solver plugin has to
do is look for [w]anted where the head of the type family application is
"Magic", [w] Magic 8 ~ fmv1.
Then perhaps do some substitution for fmv1 to get back [w] Magic 8 ~ 42,
use its internal solving rules to reduce Magic 8 to 42, and conclude what
"[w] 42 ~ 42" can be solved by reflexivity.

But in a version without flattening, all we would see is:
[W] Foo (Magic 8) ~ Foo 42

And all I can do is to traverse the entire [W]anted, look for type family
applications of "Magic" an then improve to:
[W] Foo 42 ~ Bar 42

Now... I can't declare that [W]anted solved, because i have no idea what
Foo and Bar do (they might also be type families that can only be solved
through constraint solver plugins).
Currently, the API for constraint solving plugins allows me to return
_either_:
http://hackage.haskell.org/package/ghc-8.10.1/docs/TcRnTypes.html#t:TcPluginResult
A) A set of contradictions
B) A set of solved [W] constraints + A set of new [W] constraints

With the above API, the only way to move forward is to: 1) declare "[w] Foo
(Magic 8) ~ Bar 42" solved, while at the same time emitting a new wanted
"[w] Foo 42 ~ Bar 42"
But it's basically the same wanted... so I would like a function of type
"updateWantedType :: Ct -> TcPredType -> Ct" (which I don't think exists in
the current GHC API)

But you might think the above way of working with the constraint solver as
a plugin write, where we "solve" a wanted, only to emit an "improved"
wanted, is _not_ the way things should work.
If that's the case, how do you envision plugin writers interacting with the
solver?
Note that the above way of interacting with the constraint solver,
"solving" + emitting "improved", is something I already sorta do, but in a
different context:
In "ghc-typelits-natnormalise", when asked to solve [w] "a + Foo b ~ Foo b
+ c", I solve it, but then immediately emitting "[w] a ~ c".

-- Christiaan






On Fri, 20 Nov 2020 at 20:43, Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Nov 19, 2020, at 12:40 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> Hello,
>
> I haven't worked on that stuff in Haskell for a long time, but here are
> some thoughts:
>   - I think plugins should generally be agnostic to the form of the
> constraints they are given, thus flattening or not should not affect
> them---after all, the user might have written the constraints in the
> "flattened" form in the first place.  So I think a plugin needs to convert
> the constraints to whatever form it assumes anyways.
>   - I always thought that derived constraints were a pretty clever way for
> disseminating information in the constraint solver, is there a note
> somewhere on what's going to be the new mechanism?
>
>
> This Note (
> https://gitlab.haskell.org/ghc/ghc/-/blob/wip/derived-refactor/compiler/GHC/Tc/Types/Constraint.hs#L1678)
> is the best I can offer, though it may be out of date. In the final version
> of the patch, that Note will naturally be updated. Essentially, the new
> plan is just to use Wanteds instead of Deriveds, which will achieve the
> same goal (but do not need to be distinct from Deriveds).
>
> Richard
>
>
> -Iavor
>
>
> On Thu, Nov 19, 2020 at 2:21 AM Christiaan Baaij <
> christiaan.baaij at gmail.com> wrote:
>
>> I always forget what flattening did/does. Is it the thing where it turns
>> a "complex" type family application:
>>
>> F (G y) (H z) ~ a
>>
>> into:
>>
>> G y ~ p
>> H z ~ q
>> F p q ~ a
>>
>> ?
>>
>> If so, then I'm all for removing that. Since I actually wrote/hacked a
>> function that "reverts" that process (for [G]ivens only):
>> https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens
>> Which I use in all of my plugins. (PS it should perhaps be called
>> "unflattenGiven"? like I said, I always get confused about flatten vs
>> unflatten).
>>
>> On Thu, 19 Nov 2020 at 05:20, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>>> Hi all,
>>>
>>> I'm hard at work on two significant refactorings within GHC's constraint
>>> solver. The first is at
>>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149. It removes
>>> flattening meta-variables and flattening skolems. This is a very nice
>>> simplification. Instead, it just reduces type families directly. My other
>>> patch (held up by the first) is at
>>> https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor and will
>>> remove Derived constraints, to be replaced by a little bit of cleverness in
>>> suppressing certain confusing error messages. My guess is that either or
>>> both of these will invalidate the current behavior of type-checker plugins.
>>> Sadly, this is not just a case of finding a new function that replicates
>>> the old behavior -- enough is changing under the hood that you might
>>> actually have to rewrite chunks of your code.
>>>
>>> I have never written a type-checker plugin, and so I don't currently
>>> have advice for you. But if you are a plugin author affected by this change
>>> and want help, please reach out -- I would be happy to walk you through the
>>> changes, and then hopefully make a little video explaining the process to
>>> other plugin authors.
>>>
>>> Neither patch will make it for 9.0, but I expect both to be in 9.2.
>>> There may be more where this came from (
>>> https://gitlab.haskell.org/ghc/ghc/-/issues/18965) in the future, but
>>> it's all for a good cause.
>>>
>>> (I have bcc'd plugin authors that I'm aware of. Just adding this in case
>>> you're surprised at receiving this email.)
>>>
>>> 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/20201130/a2c664aa/attachment.html>

From rae at richarde.dev  Mon Nov 30 19:03:32 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 30 Nov 2020 19:03:32 +0000
Subject: PSA: type checker plugins to be affected by upcoming changes to
 GHC
In-Reply-To: <CABzw7bUA40dW8m6G0mWQhF61TdsO5coT_CvKhYbVsqFkT45u-A@mail.gmail.com>
References: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
 <CABzw7bU100ZYogrQzqMav=DYJdtKwKaVcLkq2uhKqeeDUk2eYQ@mail.gmail.com>
 <CAGK9nuqiQRhvxo=FKup1iVK+cimWvCfJ778TjwuGf8TGuCsHWw@mail.gmail.com>
 <010f0175e72ec24f-c12ce71e-4192-4f37-befa-afb1a9b409d5-000000@us-east-2.amazonses.com>
 <CABzw7bUA40dW8m6G0mWQhF61TdsO5coT_CvKhYbVsqFkT45u-A@mail.gmail.com>
Message-ID: <010f01761a89e0a1-e00f2175-af20-40f2-aea0-910edcc29b50-000000@us-east-2.amazonses.com>



> On Nov 30, 2020, at 11:41 AM, Christiaan Baaij <christiaan.baaij at gmail.com> wrote:
> 
> Richard, I just watched your talk about simplifying the constraint solver: https://www.youtube.com/watch?v=flwz6V5Ps8w <https://www.youtube.com/watch?v=flwz6V5Ps8w>
> and then realised that no flattening at all means also no flattening of [W]anteds.

Yes, that's true.

> 
> Now, let's say I have a type family called "Magic" for which I want to write a constraint solver plugin; and some type family "Foo" and "Bar"
> And then lets say we start out with an original [W]anted: Foo (Magic 8) ~ Bar 42
> 
> Then if I understand flattening correctly, that would get flattened to:
> [w] Magic 8 ~ fmv1
> [w] fmv1 ~ 42
> [w] Foo fmv1 ~ fmv2
> [w] fmv2 ~ Bar fmv1
> 
> Correct?

I get

[W] Magic 8 ~ fmv1
[W] Foo fmv1 ~ fmv2
[W] Bar 42 ~ fmv3
[W] fmv2 ~ fmv3

> 
> So currently, with flattened wanted, all a constraint solver plugin has to do is look for [w]anted where the head of the type family application is "Magic", [w] Magic 8 ~ fmv1.
> Then perhaps do some substitution for fmv1 to get back [w] Magic 8 ~ 42, use its internal solving rules to reduce Magic 8 to 42, and conclude what "[w] 42 ~ 42" can be solved by reflexivity.

It looks like maybe you edited your example afterwards? This doesn't quite line up, because we don't have [W] Magic 8 ~ 42 anywhere. But I see your point, in that flattening brings the type family out to the top level.

> 
> But in a version without flattening, all we would see is:
> [W] Foo (Magic 8) ~ Foo 42 

Did you mean [W] Foo (Magic 8) ~ Bar 42? Then, yes.

> 
> And all I can do is to traverse the entire [W]anted, look for type family applications of "Magic" an then improve to:
> [W] Foo 42 ~ Bar 42
> 
> Now... I can't declare that [W]anted solved, because i have no idea what Foo and Bar do (they might also be type families that can only be solved through constraint solver plugins).
> Currently, the API for constraint solving plugins allows me to return _either_: http://hackage.haskell.org/package/ghc-8.10.1/docs/TcRnTypes.html#t:TcPluginResult <http://hackage.haskell.org/package/ghc-8.10.1/docs/TcRnTypes.html#t:TcPluginResult>
> A) A set of contradictions
> B) A set of solved [W] constraints + A set of new [W] constraints
> 
> With the above API, the only way to move forward is to: 1) declare "[w] Foo (Magic 8) ~ Bar 42" solved, while at the same time emitting a new wanted "[w] Foo 42 ~ Bar 42"

Yes, that's what you would do. Indeed, it's what GHC does whenever simplifying part of a Wanted.

> But it's basically the same wanted... so I would like a function of type  "updateWantedType :: Ct -> TcPredType -> Ct" (which I don't think exists in the current GHC API)

This would not be hard to write, though you'd also need evidence relating the old type and the new one. Here's an attempt (that I have not tested, beyond the ability to compile it):

> import GHC.Plugins
> import GHC.Tc.Utils.TcType
> import GHC.Tc.Types.Evidence
> import GHC.Tc.Types.Constraint
> import GHC.Tc.Plugin
> 
> updateWantedType :: Ct            -- initial constraint; always unsolved equality wanted
>                                   --   t1 ~N t2
>                  -> TcPredType    -- desired new constraint: s1 ~N s2
>                  -> CoercionN     -- lhs_co :: t1 ~N s1
>                  -> CoercionN     -- rhs_co :: t2 ~N s2
>                  -> TcPluginM (Ct, EvTerm)  -- new constraint, evidence for *old* constraint
> -- NB: the *old* constraint is solved by the returned EvTerm;
> -- return the EvTerm with the *old* constraint in TcPluginOk
> updateWantedType old_ct new_pred lhs_co rhs_co = do
>   new_w <- newWanted (ctLoc old_ct) new_pred
>   let new_co = ctEvCoercion new_w    -- :: s1 ~N s2
>       old_co = lhs_co `mkTransCo` new_co `mkTransCo` mkSymCo rhs_co
>       old_ev = evCoercion old_co
>   return (mkNonCanonical new_w, old_ev)

That would seem to do the trick. This function is essentially extracted from GHC.Tc.Solver.Canonical.rewriteEqEvidence, and GHC does it many many times while working with equalities.

> 
> But you might think the above way of working with the constraint solver as a plugin write, where we "solve" a wanted, only to emit an "improved" wanted, is _not_ the way things should work.

I don't quite know how to interpret this statement. This way of working is commonplace. For example, it's what we do when trying to prove a goal by hand when working backwards: we simplify the goal Wanted by rewriting it to another (presumably simpler) Wanted -- as long as the new Wanted can prove the old one.

> If that's the case, how do you envision plugin writers interacting with the solver?

As you've outlined above.

> Note that the above way of interacting with the constraint solver, "solving" + emitting "improved", is something I already sorta do, but in a different context:
> In "ghc-typelits-natnormalise", when asked to solve [w] "a + Foo b ~ Foo b + c", I solve it, but then immediately emitting "[w] a ~ c".

And that's really the way to do it.

A slightly different problem than the one you've outlined here is that generating the coercions to pass to updatedWantedType might be challenging. So I wonder about a new kind of plugin, called a "rewriter plugin", that looks like

> rewriterPlugin :: TyCon -> [TcType] -> TcPluginM (Maybe TcType)

possibly with some other state passed in (including other constraints, if there is demand). The tycon would always be a type family, and the types would always exactly saturate the type family. Then, the plugin could reduce the type family if it knows how to do so. This seems to be a fairly simple interface and would be very, very easy to insert into the new infrastructure. (I'm a little worried about performance, because simplifying type families is code that's hammered on. But one step at a time.) Would that satisfy your need?

Richard

> 
> -- Christiaan
> 
> 
> 
> 
> 
> 
> On Fri, 20 Nov 2020 at 20:43, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> 
> 
>> On Nov 19, 2020, at 12:40 PM, Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
>> 
>> Hello,
>> 
>> I haven't worked on that stuff in Haskell for a long time, but here are some thoughts:
>>   - I think plugins should generally be agnostic to the form of the constraints they are given, thus flattening or not should not affect them---after all, the user might have written the constraints in the "flattened" form in the first place.  So I think a plugin needs to convert the constraints to whatever form it assumes anyways.
>>   - I always thought that derived constraints were a pretty clever way for disseminating information in the constraint solver, is there a note somewhere on what's going to be the new mechanism?
> 
> This Note (https://gitlab.haskell.org/ghc/ghc/-/blob/wip/derived-refactor/compiler/GHC/Tc/Types/Constraint.hs#L1678 <https://gitlab.haskell.org/ghc/ghc/-/blob/wip/derived-refactor/compiler/GHC/Tc/Types/Constraint.hs#L1678>) is the best I can offer, though it may be out of date. In the final version of the patch, that Note will naturally be updated. Essentially, the new plan is just to use Wanteds instead of Deriveds, which will achieve the same goal (but do not need to be distinct from Deriveds).
> 
> Richard
> 
>> 
>> -Iavor
>> 
>> 
>> On Thu, Nov 19, 2020 at 2:21 AM Christiaan Baaij <christiaan.baaij at gmail.com <mailto:christiaan.baaij at gmail.com>> wrote:
>> I always forget what flattening did/does. Is it the thing where it turns a "complex" type family application:
>> 
>> F (G y) (H z) ~ a
>> 
>> into:
>> 
>> G y ~ p
>> H z ~ q
>> F p q ~ a
>> 
>> ?
>> 
>> If so, then I'm all for removing that. Since I actually wrote/hacked a function that "reverts" that process (for [G]ivens only): https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens <https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens>
>> Which I use in all of my plugins. (PS it should perhaps be called "unflattenGiven"? like I said, I always get confused about flatten vs unflatten).
>> 
>> On Thu, 19 Nov 2020 at 05:20, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>> Hi all,
>> 
>> I'm hard at work on two significant refactorings within GHC's constraint solver. The first is at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149>. It removes flattening meta-variables and flattening skolems. This is a very nice simplification. Instead, it just reduces type families directly. My other patch (held up by the first) is at https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor <https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor> and will remove Derived constraints, to be replaced by a little bit of cleverness in suppressing certain confusing error messages. My guess is that either or both of these will invalidate the current behavior of type-checker plugins. Sadly, this is not just a case of finding a new function that replicates the old behavior -- enough is changing under the hood that you might actually have to rewrite chunks of your code.
>> 
>> I have never written a type-checker plugin, and so I don't currently have advice for you. But if you are a plugin author affected by this change and want help, please reach out -- I would be happy to walk you through the changes, and then hopefully make a little video explaining the process to other plugin authors.
>> 
>> Neither patch will make it for 9.0, but I expect both to be in 9.2. There may be more where this came from (https://gitlab.haskell.org/ghc/ghc/-/issues/18965 <https://gitlab.haskell.org/ghc/ghc/-/issues/18965>) in the future, but it's all for a good cause.
>> 
>> (I have bcc'd plugin authors that I'm aware of. Just adding this in case you're surprised at receiving this email.)
>> 
>> 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 <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/20201130/d29ded6b/attachment.html>

From christiaan.baaij at gmail.com  Mon Nov 30 20:50:58 2020
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Mon, 30 Nov 2020 21:50:58 +0100
Subject: PSA: type checker plugins to be affected by upcoming changes to
 GHC
In-Reply-To: <010f01761a89e0a1-e00f2175-af20-40f2-aea0-910edcc29b50-000000@us-east-2.amazonses.com>
References: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
 <CABzw7bU100ZYogrQzqMav=DYJdtKwKaVcLkq2uhKqeeDUk2eYQ@mail.gmail.com>
 <CAGK9nuqiQRhvxo=FKup1iVK+cimWvCfJ778TjwuGf8TGuCsHWw@mail.gmail.com>
 <010f0175e72ec24f-c12ce71e-4192-4f37-befa-afb1a9b409d5-000000@us-east-2.amazonses.com>
 <CABzw7bUA40dW8m6G0mWQhF61TdsO5coT_CvKhYbVsqFkT45u-A@mail.gmail.com>
 <010f01761a89e0a1-e00f2175-af20-40f2-aea0-910edcc29b50-000000@us-east-2.amazonses.com>
Message-ID: <CABzw7bV-36ULSfefoV0zUMav5zMzCLcCYK9x9VeibC0YT+DF1w@mail.gmail.com>

Sorry for my mistakes. It is as you said, I changed the example, but didn't
properly follow through in the rest of the email.

I'm glad I've understood the intended interaction with the constraint
solver correctly then.
(With regard to the coercion... I usually just end up using UnivCo...)

It seems like a function like `rewritePlugin` is something we could/should
just build on top of the existing plugin mechanism, and have something
along the line of:

> -- | Create a 'TcPluginSolver' from the provided rewrite function
> rewritePluginSolver ::
>   (s -> TyCon -> [TcType] -> TcPluginM (Maybe TcType)) ->
>   (s -> TcPluginSolver)

where `rewritePlugin` just traverses constraints with the given rewrite and
creates the evidence, emits new wanteds, etc.
(We could develop such a function outside of the `ghc` package, and only
once we have a satisfactory solution, perhaps consider it for inclusion in
the `ghc` package.)
This way, we won't have to make the common case of simplifying type
families slow, and still provide a straightforward API.



On Mon, 30 Nov 2020 at 20:03, Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Nov 30, 2020, at 11:41 AM, Christiaan Baaij <christiaan.baaij at gmail.com>
> wrote:
>
> Richard, I just watched your talk about simplifying the constraint solver:
> https://www.youtube.com/watch?v=flwz6V5Ps8w
> and then realised that no flattening at all means also no flattening of
> [W]anteds.
>
>
> Yes, that's true.
>
>
> Now, let's say I have a type family called "Magic" for which I want to
> write a constraint solver plugin; and some type family "Foo" and "Bar"
> And then lets say we start out with an original [W]anted: Foo (Magic 8) ~
> Bar 42
>
> Then if I understand flattening correctly, that would get flattened to:
> [w] Magic 8 ~ fmv1
> [w] fmv1 ~ 42
> [w] Foo fmv1 ~ fmv2
> [w] fmv2 ~ Bar fmv1
>
> Correct?
>
>
> I get
>
> [W] Magic 8 ~ fmv1
> [W] Foo fmv1 ~ fmv2
> [W] Bar 42 ~ fmv3
> [W] fmv2 ~ fmv3
>
>
> So currently, with flattened wanted, all a constraint solver plugin has to
> do is look for [w]anted where the head of the type family application is
> "Magic", [w] Magic 8 ~ fmv1.
> Then perhaps do some substitution for fmv1 to get back [w] Magic 8 ~ 42,
> use its internal solving rules to reduce Magic 8 to 42, and conclude what
> "[w] 42 ~ 42" can be solved by reflexivity.
>
>
> It looks like maybe you edited your example afterwards? This doesn't quite
> line up, because we don't have [W] Magic 8 ~ 42 anywhere. But I see your
> point, in that flattening brings the type family out to the top level.
>
>
> But in a version without flattening, all we would see is:
> [W] Foo (Magic 8) ~ Foo 42
>
>
> Did you mean [W] Foo (Magic 8) ~ Bar 42? Then, yes.
>
>
> And all I can do is to traverse the entire [W]anted, look for type family
> applications of "Magic" an then improve to:
> [W] Foo 42 ~ Bar 42
>
> Now... I can't declare that [W]anted solved, because i have no idea what
> Foo and Bar do (they might also be type families that can only be solved
> through constraint solver plugins).
> Currently, the API for constraint solving plugins allows me to return
> _either_:
> http://hackage.haskell.org/package/ghc-8.10.1/docs/TcRnTypes.html#t:TcPluginResult
> A) A set of contradictions
> B) A set of solved [W] constraints + A set of new [W] constraints
>
> With the above API, the only way to move forward is to: 1) declare "[w]
> Foo (Magic 8) ~ Bar 42" solved, while at the same time emitting a new
> wanted "[w] Foo 42 ~ Bar 42"
>
>
> Yes, that's what you would do. Indeed, it's what GHC does whenever
> simplifying part of a Wanted.
>
> But it's basically the same wanted... so I would like a function of type
> "updateWantedType :: Ct -> TcPredType -> Ct" (which I don't think exists in
> the current GHC API)
>
>
> This would not be hard to write, though you'd also need evidence relating
> the old type and the new one. Here's an attempt (that I have not tested,
> beyond the ability to compile it):
>
> import GHC.Plugins
> import GHC.Tc.Utils.TcType
> import GHC.Tc.Types.Evidence
> import GHC.Tc.Types.Constraint
> import GHC.Tc.Plugin
>
> updateWantedType :: Ct            -- initial constraint; always unsolved
> equality wanted
>                                   --   t1 ~N t2
>                  -> TcPredType    -- desired new constraint: s1 ~N s2
>                  -> CoercionN     -- lhs_co :: t1 ~N s1
>                  -> CoercionN     -- rhs_co :: t2 ~N s2
>                  -> TcPluginM (Ct, EvTerm)  -- new constraint, evidence
> for *old* constraint
> -- NB: the *old* constraint is solved by the returned EvTerm;
> -- return the EvTerm with the *old* constraint in TcPluginOk
> updateWantedType old_ct new_pred lhs_co rhs_co = do
>   new_w <- newWanted (ctLoc old_ct) new_pred
>   let new_co = ctEvCoercion new_w    -- :: s1 ~N s2
>       old_co = lhs_co `mkTransCo` new_co `mkTransCo` mkSymCo rhs_co
>       old_ev = evCoercion old_co
>   return (mkNonCanonical new_w, old_ev)
>
>
> That would seem to do the trick. This function is essentially extracted
> from GHC.Tc.Solver.Canonical.rewriteEqEvidence, and GHC does it many many
> times while working with equalities.
>
>
> But you might think the above way of working with the constraint solver as
> a plugin write, where we "solve" a wanted, only to emit an "improved"
> wanted, is _not_ the way things should work.
>
>
> I don't quite know how to interpret this statement. This way of working is
> commonplace. For example, it's what we do when trying to prove a goal by
> hand when working backwards: we simplify the goal Wanted by rewriting it to
> another (presumably simpler) Wanted -- as long as the new Wanted can prove
> the old one.
>
> If that's the case, how do you envision plugin writers interacting with
> the solver?
>
>
> As you've outlined above.
>
> Note that the above way of interacting with the constraint solver,
> "solving" + emitting "improved", is something I already sorta do, but in a
> different context:
> In "ghc-typelits-natnormalise", when asked to solve [w] "a + Foo b ~ Foo b
> + c", I solve it, but then immediately emitting "[w] a ~ c".
>
>
> And that's really the way to do it.
>
> A slightly different problem than the one you've outlined here is that
> generating the coercions to pass to updatedWantedType might be challenging.
> So I wonder about a new kind of plugin, called a "rewriter plugin", that
> looks like
>
> > rewriterPlugin :: TyCon -> [TcType] -> TcPluginM (Maybe TcType)
>
> possibly with some other state passed in (including other constraints, if
> there is demand). The tycon would always be a type family, and the types
> would always exactly saturate the type family. Then, the plugin could
> reduce the type family if it knows how to do so. This seems to be a fairly
> simple interface and would be very, very easy to insert into the new
> infrastructure. (I'm a little worried about performance, because
> simplifying type families is code that's hammered on. But one step at a
> time.) Would that satisfy your need?
>
> Richard
>
>
> -- Christiaan
>
>
>
>
>
>
> On Fri, 20 Nov 2020 at 20:43, Richard Eisenberg <rae at richarde.dev> wrote:
>
>>
>>
>> On Nov 19, 2020, at 12:40 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>> wrote:
>>
>> Hello,
>>
>> I haven't worked on that stuff in Haskell for a long time, but here are
>> some thoughts:
>>   - I think plugins should generally be agnostic to the form of the
>> constraints they are given, thus flattening or not should not affect
>> them---after all, the user might have written the constraints in the
>> "flattened" form in the first place.  So I think a plugin needs to convert
>> the constraints to whatever form it assumes anyways.
>>   - I always thought that derived constraints were a pretty clever way
>> for disseminating information in the constraint solver, is there a note
>> somewhere on what's going to be the new mechanism?
>>
>>
>> This Note (
>> https://gitlab.haskell.org/ghc/ghc/-/blob/wip/derived-refactor/compiler/GHC/Tc/Types/Constraint.hs#L1678)
>> is the best I can offer, though it may be out of date. In the final version
>> of the patch, that Note will naturally be updated. Essentially, the new
>> plan is just to use Wanteds instead of Deriveds, which will achieve the
>> same goal (but do not need to be distinct from Deriveds).
>>
>> Richard
>>
>>
>> -Iavor
>>
>>
>> On Thu, Nov 19, 2020 at 2:21 AM Christiaan Baaij <
>> christiaan.baaij at gmail.com> wrote:
>>
>>> I always forget what flattening did/does. Is it the thing where it turns
>>> a "complex" type family application:
>>>
>>> F (G y) (H z) ~ a
>>>
>>> into:
>>>
>>> G y ~ p
>>> H z ~ q
>>> F p q ~ a
>>>
>>> ?
>>>
>>> If so, then I'm all for removing that. Since I actually wrote/hacked a
>>> function that "reverts" that process (for [G]ivens only):
>>> https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens
>>> Which I use in all of my plugins. (PS it should perhaps be called
>>> "unflattenGiven"? like I said, I always get confused about flatten vs
>>> unflatten).
>>>
>>> On Thu, 19 Nov 2020 at 05:20, Richard Eisenberg <rae at richarde.dev>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm hard at work on two significant refactorings within GHC's
>>>> constraint solver. The first is at
>>>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149. It removes
>>>> flattening meta-variables and flattening skolems. This is a very nice
>>>> simplification. Instead, it just reduces type families directly. My other
>>>> patch (held up by the first) is at
>>>> https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor and
>>>> will remove Derived constraints, to be replaced by a little bit of
>>>> cleverness in suppressing certain confusing error messages. My guess is
>>>> that either or both of these will invalidate the current behavior of
>>>> type-checker plugins. Sadly, this is not just a case of finding a new
>>>> function that replicates the old behavior -- enough is changing under the
>>>> hood that you might actually have to rewrite chunks of your code.
>>>>
>>>> I have never written a type-checker plugin, and so I don't currently
>>>> have advice for you. But if you are a plugin author affected by this change
>>>> and want help, please reach out -- I would be happy to walk you through the
>>>> changes, and then hopefully make a little video explaining the process to
>>>> other plugin authors.
>>>>
>>>> Neither patch will make it for 9.0, but I expect both to be in 9.2.
>>>> There may be more where this came from (
>>>> https://gitlab.haskell.org/ghc/ghc/-/issues/18965) in the future, but
>>>> it's all for a good cause.
>>>>
>>>> (I have bcc'd plugin authors that I'm aware of. Just adding this in
>>>> case you're surprised at receiving this email.)
>>>>
>>>> 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/20201130/5a106cdd/attachment.html>

From rae at richarde.dev  Mon Nov 30 20:57:31 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 30 Nov 2020 20:57:31 +0000
Subject: PSA: type checker plugins to be affected by upcoming changes to
 GHC
In-Reply-To: <CABzw7bV-36ULSfefoV0zUMav5zMzCLcCYK9x9VeibC0YT+DF1w@mail.gmail.com>
References: <010f0175debba514-b6a358ad-fad6-4228-bf10-beb23155e870-000000@us-east-2.amazonses.com>
 <CABzw7bU100ZYogrQzqMav=DYJdtKwKaVcLkq2uhKqeeDUk2eYQ@mail.gmail.com>
 <CAGK9nuqiQRhvxo=FKup1iVK+cimWvCfJ778TjwuGf8TGuCsHWw@mail.gmail.com>
 <010f0175e72ec24f-c12ce71e-4192-4f37-befa-afb1a9b409d5-000000@us-east-2.amazonses.com>
 <CABzw7bUA40dW8m6G0mWQhF61TdsO5coT_CvKhYbVsqFkT45u-A@mail.gmail.com>
 <010f01761a89e0a1-e00f2175-af20-40f2-aea0-910edcc29b50-000000@us-east-2.amazonses.com>
 <CABzw7bV-36ULSfefoV0zUMav5zMzCLcCYK9x9VeibC0YT+DF1w@mail.gmail.com>
Message-ID: <010f01761af23ae3-38e80636-acec-4cf1-988e-de613a4ebb2a-000000@us-east-2.amazonses.com>



> On Nov 30, 2020, at 3:50 PM, Christiaan Baaij <christiaan.baaij at gmail.com> wrote:
> 
> It seems like a function like `rewritePlugin` is something we could/should just build on top of the existing plugin mechanism, and have something along the line of:
> 
> > -- | Create a 'TcPluginSolver' from the provided rewrite function
> > rewritePluginSolver ::
> >   (s -> TyCon -> [TcType] -> TcPluginM (Maybe TcType)) -> 
> >   (s -> TcPluginSolver) <>
> 
> where `rewritePlugin` just traverses constraints with the given rewrite and creates the evidence, emits new wanteds, etc.
> (We could develop such a function outside of the `ghc` package, and only once we have a satisfactory solution, perhaps consider it for inclusion in the `ghc` package.)
> This way, we won't have to make the common case of simplifying type families slow, and still provide a straightforward API.

Ooh. I like that idea. Much more orthogonal than mine. It would mean, though, that a plugin that needs to reduce lots of type families is slower than it needs to be. (That is, my idea is slower in the common case of doing most type family reduction within GHC, but faster in the case where more type family reduction is done by plugin.) In any case, it would make a nice stepping stone for the future.

If you (for any value of you) get all the infrastructure settled, I'll happily contribute the implementation of that particular function. It would be nice if the infrastructure allows me to test, as I'll surely get it wrong a few times before getting it right.

Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201130/77d65a0d/attachment.html>