From vladislav at serokell.io  Sun Aug  2 07:43:06 2020
From: vladislav at serokell.io (Vladislav Zavialov)
Date: Sun, 2 Aug 2020 10:43:06 +0300
Subject: Using a development snapshot of happy
Message-ID: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>

Hi ghc-devs,

I’m working on the unification of parsers for terms and types, and one of the things I’d really like to make use of is a feature I implemented in ‘happy’ in October 2019 (9 months ago):

  https://github.com/simonmar/happy/pull/153

It’s been merged upstream, but there has been no release of ‘happy’, despite repeated requests:

  1. I asked for a release in December: https://github.com/simonmar/happy/issues/164
  2. Ben asked for a release a month ago: https://github.com/simonmar/happy/issues/168

I see two solutions here:

  a) Find a co-maintainer for ‘happy’ who could make releases more frequently (I understand the current maintainers probably don’t have the time to do it).
  b) Use a development snapshot of ‘happy’ in GHC

Maybe we need to do both, but one reason I’d like to see (b) in particular happen is that I can imagine introducing more features to ‘happy’ for use in GHC, and it’d be nice not to wait for a release every time. For instance, there are some changes I’d like to make to happy/alex in order to implement #17750

So here are two questions I have:

  1. Are there any objections to this idea?
  2. If not, could someone more familiar with the build process guide me as to how this should be implemented? Do I add ‘happy’ as a submodule and change something in the ./configure script, or is there more to it? Do I need to modify make/hadrian, and if so, then how?

Thanks,
- Vlad

From moritz.angermann at gmail.com  Sun Aug  2 08:18:59 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 2 Aug 2020 16:18:59 +0800
Subject: Using a development snapshot of happy
In-Reply-To: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
References: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
Message-ID: <CAKfdd-yruaX0RzVdJAthKwvUu9Yp_mFeFTd_sfnaM6N-PdwkYg@mail.gmail.com>

This dependency on alex and happy to boot ghc has been annoying, but
wasn't  that terrible until a while ago when some
ghc versions needed happy <= 1.19.11 and others happy >= 1.19.12. If
happy was part of ghc, this would not have been an issue.
As such I'd be on board with adding happy *and* alex as submodules
into the `utils` folder. And thereby reducing the external
boot dependencies of ghc!

I believe
- `compiler/ghc.cabal.in` would need to get a `build-tool-depends:`
stanza for happy and alex,
- `utils/genprimopcode/genprimopcode.cabal` same
- `utils/hpc/hpc-bin.cabal` same for happy only.
For `hadrian`, you'd need to make it aware of happy and alex packages
in `hadrian/src/Packages.hs`.
(Just follow other "util"s in there, e.g. unlit or touchy).

In general hadrian should follow cabal dependencies properly.

cheers,
 Moritz

On Sun, Aug 2, 2020 at 3:43 PM Vladislav Zavialov <vladislav at serokell.io> wrote:
>
> Hi ghc-devs,
>
> I’m working on the unification of parsers for terms and types, and one of the things I’d really like to make use of is a feature I implemented in ‘happy’ in October 2019 (9 months ago):
>
>   https://github.com/simonmar/happy/pull/153
>
> It’s been merged upstream, but there has been no release of ‘happy’, despite repeated requests:
>
>   1. I asked for a release in December: https://github.com/simonmar/happy/issues/164
>   2. Ben asked for a release a month ago: https://github.com/simonmar/happy/issues/168
>
> I see two solutions here:
>
>   a) Find a co-maintainer for ‘happy’ who could make releases more frequently (I understand the current maintainers probably don’t have the time to do it).
>   b) Use a development snapshot of ‘happy’ in GHC
>
> Maybe we need to do both, but one reason I’d like to see (b) in particular happen is that I can imagine introducing more features to ‘happy’ for use in GHC, and it’d be nice not to wait for a release every time. For instance, there are some changes I’d like to make to happy/alex in order to implement #17750
>
> So here are two questions I have:
>
>   1. Are there any objections to this idea?
>   2. If not, could someone more familiar with the build process guide me as to how this should be implemented? Do I add ‘happy’ as a submodule and change something in the ./configure script, or is there more to it? Do I need to modify make/hadrian, and if so, then how?
>
> Thanks,
> - Vlad
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From John.Ericson at Obsidian.Systems  Sun Aug  2 14:52:49 2020
From: John.Ericson at Obsidian.Systems (John Cotton Ericson)
Date: Sun, 2 Aug 2020 10:52:49 -0400
Subject: Using a development snapshot of happy
In-Reply-To: <CAKfdd-yruaX0RzVdJAthKwvUu9Yp_mFeFTd_sfnaM6N-PdwkYg@mail.gmail.com>
References: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
 <CAKfdd-yruaX0RzVdJAthKwvUu9Yp_mFeFTd_sfnaM6N-PdwkYg@mail.gmail.com>
Message-ID: <cd762ab5-9e29-079c-d0fc-8227d7e885b5@Obsidian.Systems>

Big +1 on this. There area few experiments I'd like try with Happy that 
I think this will help with, too.

On 8/2/20 4:18 AM, Moritz Angermann wrote:
> This dependency on alex and happy to boot ghc has been annoying, but
> wasn't  that terrible until a while ago when some
> ghc versions needed happy <= 1.19.11 and others happy >= 1.19.12. If
> happy was part of ghc, this would not have been an issue.
> As such I'd be on board with adding happy *and* alex as submodules
> into the `utils` folder. And thereby reducing the external
> boot dependencies of ghc!
>
> I believe
> - `compiler/ghc.cabal.in` would need to get a `build-tool-depends:`
> stanza for happy and alex,
> - `utils/genprimopcode/genprimopcode.cabal` same
> - `utils/hpc/hpc-bin.cabal` same for happy only.
> For `hadrian`, you'd need to make it aware of happy and alex packages
> in `hadrian/src/Packages.hs`.
> (Just follow other "util"s in there, e.g. unlit or touchy).
>
> In general hadrian should follow cabal dependencies properly.
>
> cheers,
>   Moritz
>
> On Sun, Aug 2, 2020 at 3:43 PM Vladislav Zavialov <vladislav at serokell.io> wrote:
>> Hi ghc-devs,
>>
>> I’m working on the unification of parsers for terms and types, and one of the things I’d really like to make use of is a feature I implemented in ‘happy’ in October 2019 (9 months ago):
>>
>>    https://github.com/simonmar/happy/pull/153
>>
>> It’s been merged upstream, but there has been no release of ‘happy’, despite repeated requests:
>>
>>    1. I asked for a release in December: https://github.com/simonmar/happy/issues/164
>>    2. Ben asked for a release a month ago: https://github.com/simonmar/happy/issues/168
>>
>> I see two solutions here:
>>
>>    a) Find a co-maintainer for ‘happy’ who could make releases more frequently (I understand the current maintainers probably don’t have the time to do it).
>>    b) Use a development snapshot of ‘happy’ in GHC
>>
>> Maybe we need to do both, but one reason I’d like to see (b) in particular happen is that I can imagine introducing more features to ‘happy’ for use in GHC, and it’d be nice not to wait for a release every time. For instance, there are some changes I’d like to make to happy/alex in order to implement #17750
>>
>> So here are two questions I have:
>>
>>    1. Are there any objections to this idea?
>>    2. If not, could someone more familiar with the build process guide me as to how this should be implemented? Do I add ‘happy’ as a submodule and change something in the ./configure script, or is there more to it? Do I need to modify make/hadrian, and if so, then how?
>>
>> Thanks,
>> - Vlad
>> _______________________________________________
>> 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 conversation at anselmschueler.com  Tue Aug  4 12:59:24 2020
From: conversation at anselmschueler.com (=?utf-8?Q?Anselm_Sch=C3=BCler_(conversations_subemail)?=)
Date: Tue, 4 Aug 2020 14:59:24 +0200
Subject: Hi. I'm new to this mailing list and have a few questions.
Message-ID: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200804/9ac5313a/attachment.html>

From rae at richarde.dev  Tue Aug  4 15:05:04 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 4 Aug 2020 15:05:04 +0000
Subject: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
Message-ID: <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>

Hi Anselm,

Welcome!

A good way of getting used to a list like this one is to wait a little while and observe what kind of messages others send; this will give you a feel for how the list is used. If you're impatient, you can also check out the archives at https://mail.haskell.org/pipermail/ghc-devs/.

As for a feature request: if your feature changes the language GHC accepts (most do), the right place to post is at https://github.com/ghc-proposals/ghc-proposals. There is a description of how to proceed on that page. Proposals submitted there get debated within the community and then eventually sent to a GHC Steering Committee for a vote on acceptance or rejection. Then, we worry about implementing it. If you have a suggestion that does not change the language GHC accepts, you can post an Issue at https://gitlab.haskell.org/ghc/ghc/.

I hope this is helpful!
Richard

> On Aug 4, 2020, at 8:59 AM, Anselm Schüler (conversations subemail) <conversation at anselmschueler.com> wrote:
> 
> First of all, in general, I’m new to mailing lists (as used for discussions) in general, so a question about that:
> When subscribed to the mailing list, do you get every message, or are some discussions hidden?
>  
> Second of all, I’d like to know what kinds of messages are appropriate here. I’m not familiar with coding compilers or anything of the like, so I’m somewhat afraid of offering unhelpful comments or being just woefully underqualified to participate here.
> For example, I have a feature idea in the back of my mind, which I imagine would be easy to implement (that might be wrong). Is it alright if I submit that here or should I use some other forum?
>  
> Thank you in advance for the answers.
>  
> Anselm Schüler
> www.anselmschueler.com <http://www.anselmschueler.com/>
> mail at anselmschueler.com <mailto:mail at anselmschueler.com>_______________________________________________
> 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/20200804/7c1e6766/attachment.html>

From simonpj at microsoft.com  Tue Aug  4 16:44:11 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Aug 2020 16:44:11 +0000
Subject: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
 <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>
Message-ID: <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Welcome Anselm.  ghc-devs is a very informal mailing list, and we welcome newcomers.

For example, I have a feature idea in the back of my mind, which I imagine would be easy to implement

What Richard says is right, but you should feel free to fly the kite on this list if you want – or on Haskell Café – to get some idea of whether others seem warm about the idea, before writing a full proposal.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 04 August 2020 16:05
To: "Anselm Schüler (conversations subemail)" <conversation at anselmschueler.com>
Cc: ghc-devs at haskell.org
Subject: Re: Hi. I'm new to this mailing list and have a few questions.

Hi Anselm,

Welcome!

A good way of getting used to a list like this one is to wait a little while and observe what kind of messages others send; this will give you a feel for how the list is used. If you're impatient, you can also check out the archives at https://mail.haskell.org/pipermail/ghc-devs/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-devs%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404154244&sdata=w4QIMTGeMQ35bEo4xkOn2rIj8z02iMVje4Ar9AXM22k%3D&reserved=0>.

As for a feature request: if your feature changes the language GHC accepts (most do), the right place to post is at https://github.com/ghc-proposals/ghc-proposals<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=ogVVk5kRFXPc81dZ%2FiyGV9FbgQoQUtzazpFGcrAKUXA%3D&reserved=0>. There is a description of how to proceed on that page. Proposals submitted there get debated within the community and then eventually sent to a GHC Steering Committee for a vote on acceptance or rejection. Then, we worry about implementing it. If you have a suggestion that does not change the language GHC accepts, you can post an Issue at https://gitlab.haskell.org/ghc/ghc/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=tg40q%2B9%2BW5KcVzHsPx9oCP7wdw5ipdZCOOdFnzUz3mU%3D&reserved=0>.

I hope this is helpful!
Richard


On Aug 4, 2020, at 8:59 AM, Anselm Schüler (conversations subemail) <conversation at anselmschueler.com<mailto:conversation at anselmschueler.com>> wrote:

First of all, in general, I’m new to mailing lists (as used for discussions) in general, so a question about that:
When subscribed to the mailing list, do you get every message, or are some discussions hidden?

Second of all, I’d like to know what kinds of messages are appropriate here. I’m not familiar with coding compilers or anything of the like, so I’m somewhat afraid of offering unhelpful comments or being just woefully underqualified to participate here.
For example, I have a feature idea in the back of my mind, which I imagine would be easy to implement (that might be wrong). Is it alright if I submit that here or should I use some other forum?

Thank you in advance for the answers.

Anselm Schüler
www.anselmschueler.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.anselmschueler.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=WJBJ3P%2BFUnTmVs9Z97DHLat9mHr6vC22l0mQ36nafGc%3D&reserved=0>
mail at anselmschueler.com<mailto:mail at anselmschueler.com>
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404174237&sdata=9y99aKPjfvm7WIH5Xv9JDlN7TIXdVPJZF%2BvAgbUvBUU%3D&reserved=0>

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

From ben at smart-cactus.org  Tue Aug  4 17:21:27 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 04 Aug 2020 13:21:27 -0400
Subject: Using a development snapshot of happy
In-Reply-To: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
References: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
Message-ID: <87o8nqfht7.fsf@smart-cactus.org>

Vladislav Zavialov <vladislav at serokell.io> writes:

> Hi ghc-devs,
>
> I’m working on the unification of parsers for terms and types, and one
> of the things I’d really like to make use of is a feature I
> implemented in ‘happy’ in October 2019 (9 months ago):
>
>   https://github.com/simonmar/happy/pull/153
>
> It’s been merged upstream, but there has been no release of ‘happy’,
> despite repeated requests:
>
>   1. I asked for a release in December: https://github.com/simonmar/happy/issues/164
>   2. Ben asked for a release a month ago: https://github.com/simonmar/happy/issues/168
>
> I see two solutions here:
>
>   a) Find a co-maintainer for ‘happy’ who could make releases more
>   frequently (I understand the current maintainers probably don’t have
>   the time to do it).
>   b) Use a development snapshot of ‘happy’ in GHC
>
> Maybe we need to do both, but one reason I’d like to see (b) in
> particular happen is that I can imagine introducing more features to
> ‘happy’ for use in GHC, and it’d be nice not to wait for a release
> every time. For instance, there are some changes I’d like to make to
> happy/alex in order to implement #17750
>
> So here are two questions I have:
>
>   1. Are there any objections to this idea?

I'm not entirely keen on the idea: while the cost of the submodule
itself is pretty low (happy is a small package which takes little time
to build), I am skeptical of addressing social issues like happy's lack
of maintenance with technical solutions. Ultimately, shipping happy as a
submodule would merely kick the current problem down the road:
eventually (when we release GHC) we will need a happy release. Unless
the underlying maintainership problem is addressed we will end up right
back where we are today.

Moreover, note that happy requires happy as a build dependency so we won't be
able to drop it as a build dependency of GHC even if we do include it as
a submodule.

For this reason, I would weakly prefer that we first find a maintainer
and try to get a release out before jumping straight to adding happy as
a submodule. I will try to bring up the matter with Simon Marlow to see
if we can't find a solution here.

>   2. If not, could someone more familiar with the build process guide
>   me as to how this should be implemented? Do I add ‘happy’ as a
>   submodule and change something in the ./configure script, or is
>   there more to it? Do I need to modify make/hadrian, and if so, then
>   how?
>
It will be a tad more involved than this. We will need to teach the
build systems to build Happy, use the configure executable, and update
the source distribution packaging rules to include the new submodule.
Moreover, happy (unfortunately) has a make-based build system which will
need to be used to generate its parser.

Updating the build systems likely won't be difficult, but there isn't clear
documentation on what it will involve. This will really be a matter of
finding a similar existing case (e.g. genprimops, perhaps?), following
it as a model, and figuring out how to fill any gaps.

Moreover, build system logic is inevitably a bug-nest; adding the same
logic twice greatly increases the chance that we will have (two sets of)
bugs that will only be caught post-release. For me, this underscores the
need to first try to make the existing decoupled situation work before
moving to a vendored solution.

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/20200804/83830cd2/attachment.sig>

From ben at well-typed.com  Tue Aug  4 17:23:09 2020
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 04 Aug 2020 13:23:09 -0400
Subject: Using a development snapshot of happy
In-Reply-To: <87o8nqfht7.fsf@smart-cactus.org>
References: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
 <87o8nqfht7.fsf@smart-cactus.org>
Message-ID: <87lfiufhqa.fsf@smart-cactus.org>

Ben Gamari <ben at smart-cactus.org> writes:

> Vladislav Zavialov <vladislav at serokell.io> writes:
>
...
> It will be a tad more involved than this. We will need to teach the
> build systems to build Happy, use the configure executable, and update

My apologies. The above should have read:

> use the *produced* executable


-------------- 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/20200804/553742b3/attachment.sig>

From conversation at anselmschueler.com  Tue Aug  4 17:45:06 2020
From: conversation at anselmschueler.com (=?utf-8?Q?Anselm_Sch=C3=BCler_(conversations_subemail)?=)
Date: Tue, 4 Aug 2020 19:45:06 +0200
Subject: AW: RE: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
 <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>,
 <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200804/93e3cd55/attachment.html>

From iavor.diatchki at gmail.com  Tue Aug  4 17:57:08 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 4 Aug 2020 10:57:08 -0700
Subject: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
 <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>
 <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>
Message-ID: <CAGK9nuo+uzZQCqn+12gA+q3a7TDVpUcS49bsaT2tpFFXx9aOeg@mail.gmail.com>

I think that's a nice idea.  In Cryptol we have both positional and named
applications (as in your outline) and it works very nicely, I think.

-Iavor

On Tue, Aug 4, 2020 at 10:46 AM Anselm Schüler (conversations subemail) <
conversation at anselmschueler.com> wrote:

> Thank you for the nice introduction :) !
>
> I will check out the GHC proposals site.
>
> And following Simon’s (I hope addressing with first name is OK)
> suggestion, I’m going to give an outline of the idea.
>
>
>
> The idea is to extend type application syntax to enable explicit
> assignment of types to specific type variables.
>
> For instance, say I have f :: forall a b. (a, b) -> (b, a), and I want to
> apply the type [String] to it. My only option is to do
>
> f @([String]) *:: forall b. ([String], b) -> (b, [String]) *
>
> —but what if, instead, I want a function of type forall a. (a, [String])
> -> ([String], a)?
>
> I propose the following syntax:
>
> f @{b = [String]} *:: forall a. ([String], b) -> (b, [String])*
>
> This wouldn’t break any existing programs since using record syntax here
> is already disallowed and met with an error message.
>
> A question is of course the symbol used for assignment (~, =, ::, or ->?).
>
>
>
> I hope the code shows up as a monospace font on your end. I used the IBM
> Plex Mono font, which is open-source <https://github.com/IBM/plex>.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com <http://www.anselmschueler.com>*
>
> *mail at anselmschueler.com <mail at anselmschueler.com>*
>
>
>
> *From: *Simon Peyton Jones <simonpj at microsoft.com>
> *Sent: *Tuesday, August 4, 2020 18:44
> *To: *Richard Eisenberg <rae at richarde.dev>; "Anselm Schüler
> (conversations subemail)" <conversation at anselmschueler.com>
> *Cc: *ghc-devs at haskell.org
> *Subject: *RE: Hi. I'm new to this mailing list and have a few questions.
>
>
>
> Welcome Anselm.  ghc-devs is a very informal mailing list, and we welcome
> newcomers.
>
>
>
> For example, I have a feature idea in the back of my mind, which I imagine
> would be easy to implement
>
>
>
> What Richard says is right, but you should feel free to fly the kite on
> this list if you want – or on Haskell Café – to get some idea of whether
> others seem warm about the idea, before writing a full proposal.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Richard
> Eisenberg
> *Sent:* 04 August 2020 16:05
> *To:* "Anselm Schüler (conversations subemail)" <
> conversation at anselmschueler.com>
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: Hi. I'm new to this mailing list and have a few questions.
>
>
>
> Hi Anselm,
>
>
>
> Welcome!
>
>
>
> A good way of getting used to a list like this one is to wait a little
> while and observe what kind of messages others send; this will give you a
> feel for how the list is used. If you're impatient, you can also check out
> the archives at https://mail.haskell.org/pipermail/ghc-devs/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-devs%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404154244&sdata=w4QIMTGeMQ35bEo4xkOn2rIj8z02iMVje4Ar9AXM22k%3D&reserved=0>
> .
>
>
>
> As for a feature request: if your feature changes the language GHC accepts
> (most do), the right place to post is at
> https://github.com/ghc-proposals/ghc-proposals
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=ogVVk5kRFXPc81dZ%2FiyGV9FbgQoQUtzazpFGcrAKUXA%3D&reserved=0>.
> There is a description of how to proceed on that page. Proposals submitted
> there get debated within the community and then eventually sent to a GHC
> Steering Committee for a vote on acceptance or rejection. Then, we worry
> about implementing it. If you have a suggestion that does not change the
> language GHC accepts, you can post an Issue at
> https://gitlab.haskell.org/ghc/ghc/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=tg40q%2B9%2BW5KcVzHsPx9oCP7wdw5ipdZCOOdFnzUz3mU%3D&reserved=0>
> .
>
>
>
> I hope this is helpful!
>
> Richard
>
>
>
> On Aug 4, 2020, at 8:59 AM, Anselm Schüler (conversations subemail) <
> conversation at anselmschueler.com> wrote:
>
>
>
> First of all, in general, I’m new to mailing lists (as used for
> discussions) in general, so a question about that:
>
> When subscribed to the mailing list, do you get *every* message, or are
> some discussions hidden?
>
>
>
> Second of all, I’d like to know what kinds of messages are appropriate
> here. I’m not familiar with coding compilers or anything of the like, so
> I’m somewhat afraid of offering unhelpful comments or being just woefully
> underqualified to participate here.
>
> For example, I have a feature idea in the back of my mind, which I imagine
> would be easy to implement (that might be wrong). Is it alright if I submit
> that here or should I use some other forum?
>
>
>
> Thank you in advance for the answers.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.anselmschueler.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=WJBJ3P%2BFUnTmVs9Z97DHLat9mHr6vC22l0mQ36nafGc%3D&reserved=0>*
>
> *mail at anselmschueler.com <mail at anselmschueler.com>*
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404174237&sdata=9y99aKPjfvm7WIH5Xv9JDlN7TIXdVPJZF%2BvAgbUvBUU%3D&reserved=0>
>
>
>
>
> _______________________________________________
> 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/20200804/5f3dae09/attachment.html>

From goemansrowan at gmail.com  Tue Aug  4 17:58:05 2020
From: goemansrowan at gmail.com (Rowan Goemans)
Date: Tue, 4 Aug 2020 19:58:05 +0200
Subject: AW: RE: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
 <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>
 <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>
Message-ID: <69041b0c-30b5-40a8-5728-928873463d9f@gmail.com>

Just as a heads up. You can achieve what you want already by doing:

f @_ @([String]) /:: forall a. (a, ///[String]/) -> (///[String]/, a)
/

Best regards,

Rowan Goemans

On 8/4/20 7:45 PM, Anselm Schüler (conversations subemail) wrote:

> Thank you for the nice introduction :) !
>
> I will check out the GHC proposals site.
>
> And following Simon’s (I hope addressing with first name is OK) 
> suggestion, I’m going to give an outline of the idea.
>
> The idea is to extend type application syntax to enable explicit 
> assignment of types to specific type variables.
>
> For instance, say I have f :: forall a b. (a, b) -> (b, a), and I want 
> to apply the type [String]to it. My only option is to do
>
> f @([String]) /:: forall b. ([String], b) -> (b, [String]) /
>
> —but what if, instead, I want a function of type forall a. (a, 
> [String]) -> ([String], a)?
>
> I propose the following syntax:
>
> f @{b = [String]} /:: forall a. ([String], b) -> (b, [String])/
>
> This wouldn’t break any existing programs since using record syntax 
> here is already disallowed and met with an error message.
>
> A question is of course the symbol used for assignment (~, =, ::, or ->?).
>
> I hope the code shows up as a monospace font on your end. I used the 
> IBM Plex Mono font, which is open-source <https://github.com/IBM/plex>.
>
> /Anselm Schüler/
>
> /www.anselmschueler.com <http://www.anselmschueler.com>/
>
> /mail at anselmschueler.com <mailto:mail at anselmschueler.com>/
>
> *From: *Simon Peyton Jones <mailto:simonpj at microsoft.com>
> *Sent: *Tuesday, August 4, 2020 18:44
> *To: *Richard Eisenberg <mailto:rae at richarde.dev>; "Anselm Schüler 
> (conversations subemail)" <mailto:conversation at anselmschueler.com>
> *Cc: *ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> *Subject: *RE: Hi. I'm new to this mailing list and have a few questions.
>
> Welcome Anselm. ghc-devs is a very informal mailing list, and we 
> welcome newcomers.
>
> For example, I have a feature idea in the back of my mind, which I 
> imagine would be easy to implement
>
> What Richard says is right, but you should feel free to fly the kite 
> on this list if you want – or on Haskell Café – to get some idea of 
> whether others seem warm about the idea, before writing a full proposal.
>
> Simon
>
> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Richard 
> Eisenberg
> *Sent:* 04 August 2020 16:05
> *To:* "Anselm Schüler (conversations subemail)" 
> <conversation at anselmschueler.com>
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: Hi. I'm new to this mailing list and have a few questions.
>
> Hi Anselm,
>
> Welcome!
>
> A good way of getting used to a list like this one is to wait a little 
> while and observe what kind of messages others send; this will give 
> you a feel for how the list is used. If you're impatient, you can also 
> check out the archives at https://mail.haskell.org/pipermail/ghc-devs/ 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-devs%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404154244&sdata=w4QIMTGeMQ35bEo4xkOn2rIj8z02iMVje4Ar9AXM22k%3D&reserved=0>.
>
> As for a feature request: if your feature changes the language GHC 
> accepts (most do), the right place to post is at 
> https://github.com/ghc-proposals/ghc-proposals 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=ogVVk5kRFXPc81dZ%2FiyGV9FbgQoQUtzazpFGcrAKUXA%3D&reserved=0>. 
> There is a description of how to proceed on that page. Proposals 
> submitted there get debated within the community and then eventually 
> sent to a GHC Steering Committee for a vote on acceptance or 
> rejection. Then, we worry about implementing it. If you have a 
> suggestion that does not change the language GHC accepts, you can post 
> an Issue at https://gitlab.haskell.org/ghc/ghc/ 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=tg40q%2B9%2BW5KcVzHsPx9oCP7wdw5ipdZCOOdFnzUz3mU%3D&reserved=0>.
>
> I hope this is helpful!
>
> Richard
>
>     On Aug 4, 2020, at 8:59 AM, Anselm Schüler (conversations
>     subemail) <conversation at anselmschueler.com
>     <mailto:conversation at anselmschueler.com>> wrote:
>
>     First of all, in general, I’m new to mailing lists (as used for
>     discussions) in general, so a question about that:
>
>     When subscribed to the mailing list, do you get/every/message, or
>     are some discussions hidden?
>
>     Second of all, I’d like to know what kinds of messages are
>     appropriate here. I’m not familiar with coding compilers or
>     anything of the like, so I’m somewhat afraid of offering unhelpful
>     comments or being just woefully underqualified to participate here.
>
>     For example, I have a feature idea in the back of my mind, which I
>     imagine would be easy to implement (that might be wrong). Is it
>     alright if I submit that here or should I use some other forum?
>
>     Thank you in advance for the answers.
>
>     /Anselm Schüler/
>
>     /www.anselmschueler.com
>     <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.anselmschueler.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=WJBJ3P%2BFUnTmVs9Z97DHLat9mHr6vC22l0mQ36nafGc%3D&reserved=0>/
>
>     /mail at anselmschueler.com <mailto:mail at anselmschueler.com>/
>
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>     <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404174237&sdata=9y99aKPjfvm7WIH5Xv9JDlN7TIXdVPJZF%2BvAgbUvBUU%3D&reserved=0>
>
>
> _______________________________________________
> 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/20200804/52cd44ab/attachment-0001.html>

From ben at smart-cactus.org  Tue Aug  4 17:58:33 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 04 Aug 2020 13:58:33 -0400
Subject: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
Message-ID: <875z9yfg3b.fsf@smart-cactus.org>

"Anselm Schüler (conversations subemail)"
<conversation at anselmschueler.com> writes:

> First of all, in general, I’m new to mailing lists (as used for
> discussions) in general, so a question about that:
>
Hi Anselm,

Welcome to the GHC community. To add to what Richard and Simon have
shared...

> When subscribed to the mailing list, do you get every message, or are
> some discussions hidden?
>
>  
>
> Second of all, I’d like to know what kinds of messages are appropriate
> here. I’m not familiar with coding compilers or anything of the like,
> so I’m somewhat afraid of offering unhelpful comments or being just
> woefully underqualified to participate here.
>
You shouldn't worry. We are all learning.

> For example, I have a feature idea in the back of my mind, which I
> imagine would be easy to implement (that might be wrong). Is it
> alright if I submit that here or should I use some other forum?
>
The answer here depends upon what sort of feature you are thinking of.
As Simon and Richard said, the proposals process [1] exists to hone
proposals to the language and large compiler features.

In the case of a smaller feature of the compiler itself (e.g. a new GHCi
command or GHC API interface), then it can sometimes be useful to either
open an issue or mailing list thread first to help guide your thinking
and help others get a sense for the scale of the change; it's possible
that in this case a proposal isn't necessary.

Don't hesitate to reach out if you would like further guidance.

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/20200804/5d861d00/attachment.sig>

From vladislav at serokell.io  Tue Aug  4 18:04:07 2020
From: vladislav at serokell.io (Vladislav Zavialov)
Date: Tue, 4 Aug 2020 21:04:07 +0300
Subject: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
 <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>
 <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>
Message-ID: <B3C538FB-0CDA-459E-8BF1-003B8D52DFDA@serokell.io>

This feature has already been proposed:

  https://github.com/ghc-proposals/ghc-proposals/pull/196

But the discussion there has stalled. You may want to take a look at the existing discussion, and if you see a way forward, comment on the proposal (or open a competing one).

- Vlad

> On 4 Aug 2020, at 20:45, Anselm Schüler (conversations subemail) <conversation at anselmschueler.com> wrote:
> 
> Thank you for the nice introduction :) !
> I will check out the GHC proposals site.
> And following Simon’s (I hope addressing with first name is OK) suggestion, I’m going to give an outline of the idea.
>  
> The idea is to extend type application syntax to enable explicit assignment of types to specific type variables.
> For instance, say I have f :: forall a b. (a, b) -> (b, a), and I want to apply the type [String] to it. My only option is to do
> f @([String]) :: forall b. ([String], b) -> (b, [String]) 
> —but what if, instead, I want a function of type forall a. (a, [String]) -> ([String], a)?
> I propose the following syntax:
> f @{b = [String]} :: forall a. ([String], b) -> (b, [String])
> This wouldn’t break any existing programs since using record syntax here is already disallowed and met with an error message.
> A question is of course the symbol used for assignment (~, =, ::, or ->?).
>  
> I hope the code shows up as a monospace font on your end. I used the IBM Plex Mono font, which is open-source.
>  
> Anselm Schüler
> www.anselmschueler.com
> mail at anselmschueler.com
>  
> From: Simon Peyton Jones
> Sent: Tuesday, August 4, 2020 18:44
> To: Richard Eisenberg; "Anselm Schüler (conversations subemail)"
> Cc: ghc-devs at haskell.org
> Subject: RE: Hi. I'm new to this mailing list and have a few questions.
>  
> Welcome Anselm.  ghc-devs is a very informal mailing list, and we welcome newcomers.
>  
> For example, I have a feature idea in the back of my mind, which I imagine would be easy to implement
>  
> What Richard says is right, but you should feel free to fly the kite on this list if you want – or on Haskell Café – to get some idea of whether others seem warm about the idea, before writing a full proposal.  
>  
> Simon
>  
> From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Richard Eisenberg
> Sent: 04 August 2020 16:05
> To: "Anselm Schüler (conversations subemail)" <conversation at anselmschueler.com>
> Cc: ghc-devs at haskell.org
> Subject: Re: Hi. I'm new to this mailing list and have a few questions.
>  
> Hi Anselm,
>  
> Welcome!
>  
> A good way of getting used to a list like this one is to wait a little while and observe what kind of messages others send; this will give you a feel for how the list is used. If you're impatient, you can also check out the archives at https://mail.haskell.org/pipermail/ghc-devs/.
>  
> As for a feature request: if your feature changes the language GHC accepts (most do), the right place to post is at https://github.com/ghc-proposals/ghc-proposals. There is a description of how to proceed on that page. Proposals submitted there get debated within the community and then eventually sent to a GHC Steering Committee for a vote on acceptance or rejection. Then, we worry about implementing it. If you have a suggestion that does not change the language GHC accepts, you can post an Issue at https://gitlab.haskell.org/ghc/ghc/.
>  
> I hope this is helpful!
> Richard
>  
> 
> On Aug 4, 2020, at 8:59 AM, Anselm Schüler (conversations subemail) <conversation at anselmschueler.com> wrote:
>  
> First of all, in general, I’m new to mailing lists (as used for discussions) in general, so a question about that:
> When subscribed to the mailing list, do you get every message, or are some discussions hidden?
>  
> Second of all, I’d like to know what kinds of messages are appropriate here. I’m not familiar with coding compilers or anything of the like, so I’m somewhat afraid of offering unhelpful comments or being just woefully underqualified to participate here.
> For example, I have a feature idea in the back of my mind, which I imagine would be easy to implement (that might be wrong). Is it alright if I submit that here or should I use some other forum?
>  
> Thank you in advance for the answers.
>  
> Anselm Schüler
> www.anselmschueler.com
> mail at anselmschueler.com
> _______________________________________________
> 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 conversation at anselmschueler.com  Tue Aug  4 18:08:34 2020
From: conversation at anselmschueler.com (=?utf-8?Q?Anselm_Sch=C3=BCler_(conversations_subemail)?=)
Date: Tue, 4 Aug 2020 20:08:34 +0200
Subject: AW: RE: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <69041b0c-30b5-40a8-5728-928873463d9f@gmail.com>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
 <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>
 <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>,
 <69041b0c-30b5-40a8-5728-928873463d9f@gmail.com>
Message-ID: <0015429B-BDD7-4D1F-AEDC-F4EC843E3FB4@hxcore.ol>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200804/15412316/attachment.html>

From conversation at anselmschueler.com  Tue Aug  4 18:11:54 2020
From: conversation at anselmschueler.com (=?utf-8?Q?Anselm_Sch=C3=BCler_(conversations_subemail)?=)
Date: Tue, 4 Aug 2020 20:11:54 +0200
Subject: AW: RE: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <0015429B-BDD7-4D1F-AEDC-F4EC843E3FB4@hxcore.ol>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
 <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>
 <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>, 
 <69041b0c-30b5-40a8-5728-928873463d9f@gmail.com>,
 <0015429B-BDD7-4D1F-AEDC-F4EC843E3FB4@hxcore.ol>
Message-ID: <1DCAADE2-BB36-4A7C-90EE-974E34CB1ECA@hxcore.ol>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200804/0ec52229/attachment.html>

From allbery.b at gmail.com  Tue Aug  4 18:16:05 2020
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 4 Aug 2020 14:16:05 -0400
Subject: AW: RE: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <1DCAADE2-BB36-4A7C-90EE-974E34CB1ECA@hxcore.ol>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
 <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>
 <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>
 <69041b0c-30b5-40a8-5728-928873463d9f@gmail.com>
 <0015429B-BDD7-4D1F-AEDC-F4EC843E3FB4@hxcore.ol>
 <1DCAADE2-BB36-4A7C-90EE-974E34CB1ECA@hxcore.ol>
Message-ID: <CAKFCL4WXEEDc11E7pTe30Q8syxrEMEm1qhw=HEnzXQZocfq1Lg@mail.gmail.com>

_ already has the meaning of a type wildcard (generalized from its use as a
wildcard in patterns), so this
is consistent with its use in other type signatures. The problem I see with
your proposal is that it assumes
you know the names of the type variables in the original declaration.

On Tue, Aug 4, 2020 at 2:12 PM Anselm Schüler (conversations subemail) <
conversation at anselmschueler.com> wrote:

> And also, it’s really weird and seems like a feature that should be
> removed IMO. It kind of looks like the type variable _ is always
> in-scope, and it’s unclear if the type of the resulting function is just
> type variables without an explicit forall or if _ has a special meaning.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com <http://www.anselmschueler.com>*
>
>
>
> *From: *Anselm Schüler (conversations subemail)
> <conversation at anselmschueler.com>
> *Sent: *Tuesday, August 4, 2020 20:09
> *To: *Rowan Goemans <goemansrowan at gmail.com>; ghc-devs at haskell.org
> *Subject: *RE: AW: RE: Hi. I'm new to this mailing list and have a few
> questions.
>
>
>
> True, but this makes the type less readable since id @_ :: _ -> _.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com <http://www.anselmschueler.com>*
>
>
>
> *From: *Rowan Goemans <goemansrowan at gmail.com>
> *Sent: *Tuesday, August 4, 2020 19:59
> *To: *ghc-devs at haskell.org
> *Subject: *Re: AW: RE: Hi. I'm new to this mailing list and have a few
> questions.
>
>
>
> Just as a heads up. You can achieve what you want already by doing:
>
> f @_ @([String]) *:: forall a. (a, [String]) -> ([String], a**) *
>
> Best regards,
>
> Rowan Goemans
>
> On 8/4/20 7:45 PM, Anselm Schüler (conversations subemail) wrote:
>
> Thank you for the nice introduction :) !
>
> I will check out the GHC proposals site.
>
> And following Simon’s (I hope addressing with first name is OK)
> suggestion, I’m going to give an outline of the idea.
>
>
>
> The idea is to extend type application syntax to enable explicit
> assignment of types to specific type variables.
>
> For instance, say I have f :: forall a b. (a, b) -> (b, a), and I want to
> apply the type [String] to it. My only option is to do
>
> f @([String]) *:: forall b. ([String], b) -> (b, [String]) *
>
> —but what if, instead, I want a function of type forall a. (a, [String])
> -> ([String], a)?
>
> I propose the following syntax:
>
> f @{b = [String]} *:: forall a. ([String], b) -> (b, [String])*
>
> This wouldn’t break any existing programs since using record syntax here
> is already disallowed and met with an error message.
>
> A question is of course the symbol used for assignment (~, =, ::, or ->?).
>
>
>
> I hope the code shows up as a monospace font on your end. I used the IBM
> Plex Mono font, which is open-source <https://github.com/IBM/plex>.
>
>
>
> *Anselm Schüler*
>
> *wwwanselmschueler.com <http://www.anselmschueler.com>*
>
> *mail at anselmschueler.com <mail at anselmschueler.com>*
>
>
>
> *From: *Simon Peyton Jones <simonpj at microsoft.com>
> *Sent: *Tuesday, August 4, 2020 18:44
> *To: *Richard Eisenberg <rae at richarde.dev>; "Anselm Schüler
> (conversations subemail)" <conversation at anselmschueler.com>
> *Cc: *ghc-devs at haskell.org
> *Subject: *RE: Hi. I'm new to this mailing list and have a few questions.
>
>
>
> Welcome Anselm  ghc-devs is a very informal mailing list, and we welcome
> newcomers.
>
>
>
> For example, I have a feature idea in the back of my mind, which I imagine
> would be easy to implement
>
>
>
> What Richard says is right, but you should feel free to fly the kite on
> this list if you want – or on Haskell Café – to get some idea of whether
> others seem warm about the idea, before writing a full proposal.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs <ghc-devs-bounces at haskell.org>
> <ghc-devs-bounces at haskell.org> *On Behalf Of *Richard Eisenberg
> *Sent:* 04 August 2020 16:05
> *To:* "Anselm Schüler (conversations subemail)"
> <conversation at anselmschuelercom> <conversation at anselmschueler.com>
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: Hi. I'm new to this mailing list and have a few questions.
>
>
>
> Hi Anselm,
>
>
>
> Welcome!
>
>
>
> A good way of getting used to a list like this one is to wait a little
> while and observe what kind of messages others send; this will give you a
> feel for how the list is used. If you're impatient, you can also check out
> the archives at https://mail.haskell.org/pipermail/ghc-devs/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-devs%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404154244&sdata=w4QIMTGeMQ35bEo4xkOn2rIj8z02iMVje4Ar9AXM22k%3D&reserved=0>
> .
>
>
>
> As for a feature request: if your feature changes the language GHC accepts
> (most do), the right place to post is at
> https://githubcom/ghc-proposals/ghc-proposals
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=ogVVk5kRFXPc81dZ%2FiyGV9FbgQoQUtzazpFGcrAKUXA%3D&reserved=0>.
> There is a description of how to proceed on that page. Proposals submitted
> there get debated within the community and then eventually sent to a GHC
> Steering Committee for a vote on acceptance or rejection. Then, we worry
> about implementing it. If you have a suggestion that does not change the
> language GHC accepts, you can post an Issue at
> https://gitlab.haskell.org/ghc/ghc/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=tg40q%2B9%2BW5KcVzHsPx9oCP7wdw5ipdZCOOdFnzUz3mU%3D&reserved=0>
> .
>
>
>
> I hope this is helpful!
>
> Richard
>
>
>
> On Aug 4, 2020, at 8:59 AM, Anselm Schüler (conversations subemail) <
> conversation at anselmschueler.com> wrote:
>
>
>
> First of all, in general, I’m new to mailing lists (as used for
> discussions) in general, so a question about that:
>
> When subscribed to the mailing list, do you get *every* message, or are
> some discussions hidden?
>
>
>
> Second of all, I’d like to know what kinds of messages are appropriate
> here. I’m not familiar with coding compilers or anything of the like, so
> I’m somewhat afraid of offering unhelpful comments or being just woefully
> underqualified to participate here.
>
> For example, I have a feature idea in the back of my mind, which I imagine
> would be easy to implement (that might be wrong). Is it alright if I submit
> that here or should I use some other forum?
>
>
>
> Thank you in advance for the answers.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.anselmschueler.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=WJBJ3P%2BFUnTmVs9Z97DHLat9mHr6vC22l0mQ36nafGc%3D&reserved=0>*
>
> *mail at anselmschueler.com <mail at anselmschueler.com>*
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404174237&sdata=9y99aKPjfvm7WIH5Xv9JDlN7TIXdVPJZF%2BvAgbUvBUU%3D&reserved=0>
>
>
>
>
>
>
>
> _______________________________________________
>
> 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
>


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

From conversation at anselmschueler.com  Tue Aug  4 18:26:57 2020
From: conversation at anselmschueler.com (=?utf-8?Q?Anselm_Sch=C3=BCler_(conversations_subemail)?=)
Date: Tue, 4 Aug 2020 20:26:57 +0200
Subject: AW: RE: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <CAKFCL4WXEEDc11E7pTe30Q8syxrEMEm1qhw=HEnzXQZocfq1Lg@mail.gmail.com>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
 <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>
 <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>
 <69041b0c-30b5-40a8-5728-928873463d9f@gmail.com>
 <0015429B-BDD7-4D1F-AEDC-F4EC843E3FB4@hxcore.ol>
 <1DCAADE2-BB36-4A7C-90EE-974E34CB1ECA@hxcore.ol>,
 <CAKFCL4WXEEDc11E7pTe30Q8syxrEMEm1qhw=HEnzXQZocfq1Lg@mail.gmail.com>
Message-ID: <16EF275A-04CF-42E8-86DD-64C117459D4A@hxcore.ol>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200804/89d6a1ca/attachment-0001.html>

From allbery.b at gmail.com  Tue Aug  4 18:37:05 2020
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 4 Aug 2020 14:37:05 -0400
Subject: AW: RE: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <16EF275A-04CF-42E8-86DD-64C117459D4A@hxcore.ol>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
 <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>
 <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>
 <69041b0c-30b5-40a8-5728-928873463d9f@gmail.com>
 <0015429B-BDD7-4D1F-AEDC-F4EC843E3FB4@hxcore.ol>
 <1DCAADE2-BB36-4A7C-90EE-974E34CB1ECA@hxcore.ol>
 <CAKFCL4WXEEDc11E7pTe30Q8syxrEMEm1qhw=HEnzXQZocfq1Lg@mail.gmail.com>
 <16EF275A-04CF-42E8-86DD-64C117459D4A@hxcore.ol>
Message-ID: <CAKFCL4WuUBfrfqRRkqXPCW12DBTRJn6s2_o3SMOS5XCT4O-ZJQ@mail.gmail.com>

It's represented the same way but handled differently; my point, though,
was more about it being consistent with the rest of the language, which is
less about how the compiler handles it than about how it looks to the
programmer. In this case, _ is consistently used to mean a wildcard of some
kind, even though it has to be handled by the compiler in multiple places
including TypeApplications and PartialTypeSignatures (others include
patterns, typed holes, and let bindings as an extension of simple patterns).

On Tue, Aug 4, 2020 at 2:27 PM Anselm Schüler (conversations subemail) <
conversation at anselmschueler.com> wrote:

> That’s true, but type wildcards without PartialTypeSignatures throw an
> error, while this doesn’t need that (which suggests that they’re
> represented differently internally — I don’t know, of course). Also, there
> are other drawbacks discussed in the ghc-proposals Proposal
> 0042-named-type-args
> <https://github.com/ghc-proposals/ghc-proposals/pull/196> that was
> mentioned by Vladislav Zavialov <vladislav at serokell.io>. Which is, I
> think, it seems, where the discussion should take place (?).
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com* <http://www.anselmschueler.com>
>
> *mail at anselmschueler.com* <mail at anselmschueler.com>
>
>
>
> *From: *Brandon Allbery <allbery.b at gmail.com>
> *Sent: *Tuesday, August 4, 2020 20:16
> *To: *Anselm Schüler (conversations subemail)
> <conversation at anselmschueler.com>
> *Cc: *Rowan Goemans <goemansrowan at gmail.com>; ghc-devs at haskell.org
> *Subject: *Re: AW: RE: Hi. I'm new to this mailing list and have a few
> questions.
>
>
>
> _ already has the meaning of a type wildcard (generalized from its use as
> a wildcard in patterns), so this
>
> is consistent with its use in other type signatures. The problem I see
> with your proposal is that it assumes
>
> you know the names of the type variables in the original declaration.
>
>
>
> On Tue, Aug 4, 2020 at 2:12 PM Anselm Schüler (conversations subemail) <
> conversation at anselmschueler.com> wrote:
>
> And also, it’s really weird and seems like a feature that should be
> removed IMO. It kind of looks like the type variable _ is always
> in-scope, and it’s unclear if the type of the resulting function is just
> type variables without an explicit forall or if _ has a special meaning.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com <http://www.anselmschueler.com>*
>
>
>
> *From: *Anselm Schüler (conversations subemail)
> <conversation at anselmschueler.com>
> *Sent: *Tuesday, August 4, 2020 20:09
> *To: *Rowan Goemans <goemansrowan at gmail.com>; ghc-devs at haskell.org
> *Subject: *RE: AW: RE: Hi. I'm new to this mailing list and have a few
> questions.
>
>
>
> True, but this makes the type less readable since id @_ :: _ -> _.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com <http://www.anselmschueler.com>*
>
>
>
> *From: *Rowan Goemans <goemansrowan at gmail.com>
> *Sent: *Tuesday, August 4, 2020 19:59
> *To: *ghc-devs at haskell.org <ghc-devs at haskellorg>
> *Subject: *Re: AW: RE: Hi. I'm new to this mailing list and have a few
> questions.
>
>
>
> Just as a heads up. You can achieve what you want already by doing:
>
> f @_ @([String]) *:: forall a. (a, [String]) -> ([String], a**) *
>
> Best regards,
>
> Rowan Goemans
>
> On 8/4/20 7:45 PM, Anselm Schüler (conversations subemail) wrote:
>
> Thank you for the nice introduction :) !
>
> I will check out the GHC proposals site.
>
> And following Simon’s (I hope addressing with first name is OK)
> suggestion, I’m going to give an outline of the idea.
>
>
>
> The idea is to extend type application syntax to enable explicit
> assignment of types to specific type variables.
>
> For instance, say I have f :: forall a b. (a, b) -> (b, a), and I want to
> apply the type [String] to it. My only option is to do
>
> f @([String]) *:: forall b. ([String], b) -> (b, [String]) *
>
> —but what if, instead, I want a function of type forall a. (a, [String])
> -> ([String], a)?
>
> I propose the following syntax:
>
> f @{b = [String]} *:: forall a. ([String], b) -> (b, [String])*
>
> This wouldn’t break any existing programs since using record syntax here
> is already disallowed and met with an error message.
>
> A question is of course the symbol used for assignment (~, =, ::, or ->?).
>
>
>
> I hope the code shows up as a monospace font on your end. I used the IBM
> Plex Mono font, which is open-source <https://github.com/IBM/plex>.
>
>
>
> *Anselm Schüler*
>
> *wwwanselmschueler.com <http://www.anselmschueler.com>*
>
> *mail at anselmschueler.com <mail at anselmschueler.com>*
>
>
>
> *From: *Simon Peyton Jones <simonpj at microsoft.com>
> *Sent: *Tuesday, August 4, 2020 18:44
> *To: *Richard Eisenberg <rae at richarde.dev>; "Anselm Schüler
> (conversations subemail)" <conversation at anselmschueler.com>
> *Cc: *ghc-devs at haskell.org
> *Subject: *RE: Hi. I'm new to this mailing list and have a few questions.
>
>
>
> Welcome Anselm  ghc-devs is a very informal mailing list, and we welcome
> newcomers.
>
>
>
> For example, I have a feature idea in the back of my mind, which I imagine
> would be easy to implement
>
>
>
> What Richard says is right, but you should feel free to fly the kite on
> this list if you want – or on Haskell Café – to get some idea of whether
> others seem warm about the idea, before writing a full proposal.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs <ghc-devs-bounces at haskellorg>
> <ghc-devs-bounces at haskell.org> *On Behalf Of *Richard Eisenberg
> *Sent:* 04 August 2020 16:05
> *To:* "Anselm Schüler (conversations subemail)"
> <conversation at anselmschuelercom> <conversation at anselmschueler.com>
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: Hi. I'm new to this mailing list and have a few questions.
>
>
>
> Hi Anselm,
>
>
>
> Welcome!
>
>
>
> A good way of getting used to a list like this one is to wait a little
> while and observe what kind of messages others send; this will give you a
> feel for how the list is used. If you're impatient, you can also check out
> the archives at https://mail.haskell.org/pipermail/ghc-devs/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-devs%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404154244&sdata=w4QIMTGeMQ35bEo4xkOn2rIj8z02iMVje4Ar9AXM22k%3D&reserved=0>
> .
>
>
>
> As for a feature request: if your feature changes the language GHC accepts
> (most do), the right place to post is at
> https://githubcom/ghc-proposals/ghc-proposals
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=ogVVk5kRFXPc81dZ%2FiyGV9FbgQoQUtzazpFGcrAKUXA%3D&reserved=0>.
> There is a description of how to proceed on that page. Proposals submitted
> there get debated within the community and then eventually sent to a GHC
> Steering Committee for a vote on acceptance or rejection. Then, we worry
> about implementing it. If you have a suggestion that does not change the
> language GHC accepts, you can post an Issue at
> https://gitlab.haskell.org/ghc/ghc/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=tg40q%2B9%2BW5KcVzHsPx9oCP7wdw5ipdZCOOdFnzUz3mU%3D&reserved=0>
> .
>
>
>
> I hope this is helpful!
>
> Richard
>
>
>
> On Aug 4, 2020, at 8:59 AM, Anselm Schüler (conversations subemail) <
> conversation at anselmschueler.com> wrote:
>
>
>
> First of all, in general, I’m new to mailing lists (as used for
> discussions) in general, so a question about that:
>
> When subscribed to the mailing list, do you get *every* message, or are
> some discussions hidden?
>
>
>
> Second of all, I’d like to know what kinds of messages are appropriate
> here. I’m not familiar with coding compilers or anything of the like, so
> I’m somewhat afraid of offering unhelpful comments or being just woefully
> underqualified to participate here.
>
> For example, I have a feature idea in the back of my mind, which I imagine
> would be easy to implement (that might be wrong). Is it alright if I submit
> that here or should I use some other forum?
>
>
>
> Thank you in advance for the answers.
>
>
>
> *Anselm Schüler*
>
> *www.anselmschueler.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.anselmschueler.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=WJBJ3P%2BFUnTmVs9Z97DHLat9mHr6vC22l0mQ36nafGc%3D&reserved=0>*
>
> *mail at anselmschueler.com <mail at anselmschueler.com>*
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404174237&sdata=9y99aKPjfvm7WIH5Xv9JDlN7TIXdVPJZF%2BvAgbUvBUU%3D&reserved=0>
>
>
>
>
>
>
>
> _______________________________________________
>
> 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
>
>
>
>
> --
>
> brandon s allbery kf8nh
>
> allbery.b at gmail.com
>
>
>


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

From rae at richarde.dev  Tue Aug  4 18:57:15 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 4 Aug 2020 18:57:15 +0000
Subject: Hi. I'm new to this mailing list and have a few questions.
In-Reply-To: <CAKFCL4WuUBfrfqRRkqXPCW12DBTRJn6s2_o3SMOS5XCT4O-ZJQ@mail.gmail.com>
References: <695B0FF2-863B-4200-A384-B4FC96E4EBE5@hxcore.ol>
 <010f0173ba012768-7b1a4a73-e16e-43cb-aa95-7d21c0214f99-000000@us-east-2.amazonses.com>
 <VI1PR83MB04294289CCD68A4FA83E1AA9AD4A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <1F3EEFFF-DABA-433F-921D-49D28EEF3A1A@hxcore.ol>
 <69041b0c-30b5-40a8-5728-928873463d9f@gmail.com>
 <0015429B-BDD7-4D1F-AEDC-F4EC843E3FB4@hxcore.ol>
 <1DCAADE2-BB36-4A7C-90EE-974E34CB1ECA@hxcore.ol>
 <CAKFCL4WXEEDc11E7pTe30Q8syxrEMEm1qhw=HEnzXQZocfq1Lg@mail.gmail.com>
 <16EF275A-04CF-42E8-86DD-64C117459D4A@hxcore.ol>
 <CAKFCL4WuUBfrfqRRkqXPCW12DBTRJn6s2_o3SMOS5XCT4O-ZJQ@mail.gmail.com>
Message-ID: <010f0173bad5b839-7e5478bc-25cc-415b-bdf5-187fa5ca0942-000000@us-east-2.amazonses.com>

Your idea is a good one. To add to Iavor's mention about Cryptol, Agda uses both positional and named parameters, and they seem to have a good time with it.

To be honest, if I could go back in time, I would think much harder about the decision to do ordered parameters in GHC. I'm very sympathetic to this direction of travel, but unsure about the costs (code breakage, etc.) of doing so.

Do comment on the proposal thread, Anselm! :) We need motivated people like you to keep those conversations going.

Richard

PS: And, yes, I believe everyone here is on a casual, first-name basis.

> On Aug 4, 2020, at 2:37 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
> 
> It's represented the same way but handled differently; my point, though, was more about it being consistent with the rest of the language, which is less about how the compiler handles it than about how it looks to the programmer. In this case, _ is consistently used to mean a wildcard of some kind, even though it has to be handled by the compiler in multiple places including TypeApplications and PartialTypeSignatures (others include patterns, typed holes, and let bindings as an extension of simple patterns).
> 
> On Tue, Aug 4, 2020 at 2:27 PM Anselm Schüler (conversations subemail) <conversation at anselmschueler.com <mailto:conversation at anselmschueler.com>> wrote:
> That’s true, but type wildcards without PartialTypeSignatures throw an error, while this doesn’t need that (which suggests that they’re represented differently internally — I don’t know, of course). Also, there are other drawbacks discussed in the ghc-proposals Proposal 0042-named-type-args <https://github.com/ghc-proposals/ghc-proposals/pull/196> that was mentioned by Vladislav Zavialov <mailto:vladislav at serokell.io>. Which is, I think, it seems, where the discussion should take place (?).
> 
>  
> 
> Anselm Schüler
> 
> www.anselmschueler.com <http://www.anselmschueler.com/>
> mail at anselmschueler.com <mailto:mail at anselmschueler.com>
>  
> 
> From: Brandon Allbery <mailto:allbery.b at gmail.com>
> Sent: Tuesday, August 4, 2020 20:16
> To: Anselm Schüler (conversations subemail) <mailto:conversation at anselmschueler.com>
> Cc: Rowan Goemans <mailto:goemansrowan at gmail.com>; ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> Subject: Re: AW: RE: Hi. I'm new to this mailing list and have a few questions.
> 
>  
> 
> _ already has the meaning of a type wildcard (generalized from its use as a wildcard in patterns), so this
> 
> is consistent with its use in other type signatures. The problem I see with your proposal is that it assumes
> 
> you know the names of the type variables in the original declaration.
> 
>  
> 
> On Tue, Aug 4, 2020 at 2:12 PM Anselm Schüler (conversations subemail) <conversation at anselmschueler.com <mailto:conversation at anselmschueler.com>> wrote:
> 
> And also, it’s really weird and seems like a feature that should be removed IMO. It kind of looks like the type variable _ is always in-scope, and it’s unclear if the type of the resulting function is just type variables without an explicit forall or if _ has a special meaning.
> 
>  
> Anselm Schüler
> 
> www.anselmschueler.com <http://www.anselmschueler.com/>
>  
> From: Anselm Schüler (conversations subemail) <mailto:conversation at anselmschueler.com>
> Sent: Tuesday, August 4, 2020 20:09
> To: Rowan Goemans <mailto:goemansrowan at gmail.com>; ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> Subject: RE: AW: RE: Hi. I'm new to this mailing list and have a few questions.
> 
>  
> True, but this makes the type less readable since id @_ :: _ -> _.
> 
>  
> Anselm Schüler
> 
> www.anselmschueler.com <http://www.anselmschueler.com/>
>  
> From: Rowan Goemans <mailto:goemansrowan at gmail.com>
> Sent: Tuesday, August 4, 2020 19:59
> To: ghc-devs at haskell.org <mailto:ghc-devs at haskellorg>
> Subject: Re: AW: RE: Hi. I'm new to this mailing list and have a few questions.
> 
>  
> Just as a heads up. You can achieve what you want already by doing:
> 
> f @_ @([String]) :: forall a. (a, [String]) -> ([String], a) 
> 
> Best regards,
> 
> Rowan Goemans
> 
> On 8/4/20 7:45 PM, Anselm Schüler (conversations subemail) wrote:
> 
> Thank you for the nice introduction :) !
> 
> I will check out the GHC proposals site.
> 
> And following Simon’s (I hope addressing with first name is OK) suggestion, I’m going to give an outline of the idea.
> 
>  
> The idea is to extend type application syntax to enable explicit assignment of types to specific type variables.
> 
> For instance, say I have f :: forall a b. (a, b) -> (b, a), and I want to apply the type [String] to it. My only option is to do
> 
> f @([String]) :: forall b. ([String], b) -> (b, [String]) 
> 
> —but what if, instead, I want a function of type forall a. (a, [String]) -> ([String], a)?
> 
> I propose the following syntax:
> 
> f @{b = [String]} :: forall a. ([String], b) -> (b, [String])
> 
> This wouldn’t break any existing programs since using record syntax here is already disallowed and met with an error message.
> 
> A question is of course the symbol used for assignment (~, =, ::, or ->?).
> 
>  
> I hope the code shows up as a monospace font on your end. I used the IBM Plex Mono font, which is open-source <https://github.com/IBM/plex>.
> 
>  
> Anselm Schüler
> 
> wwwanselmschueler.com <http://www.anselmschueler.com/>
> mail at anselmschueler.com <mailto:mail at anselmschueler.com>
>  
> From: Simon Peyton Jones <mailto:simonpj at microsoft.com>
> Sent: Tuesday, August 4, 2020 18:44
> To: Richard Eisenberg <mailto:rae at richarde.dev>; "Anselm Schüler (conversations subemail)" <mailto:conversation at anselmschueler.com>
> Cc: ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> Subject: RE: Hi. I'm new to this mailing list and have a few questions.
> 
>  
> Welcome Anselm  ghc-devs is a very informal mailing list, and we welcome newcomers.
> 
>  
> For example, I have a feature idea in the back of my mind, which I imagine would be easy to implement
> 
>  
> What Richard says is right, but you should feel free to fly the kite on this list if you want – or on Haskell Café – to get some idea of whether others seem warm about the idea, before writing a full proposal.  
> 
>  
> Simon
> 
>  
> From: ghc-devs <ghc-devs-bounces at haskellorg> <mailto:ghc-devs-bounces at haskell.org> On Behalf Of Richard Eisenberg
> Sent: 04 August 2020 16:05
> To: "Anselm Schüler (conversations subemail)" <conversation at anselmschuelercom> <mailto:conversation at anselmschueler.com>
> Cc: ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> Subject: Re: Hi. I'm new to this mailing list and have a few questions.
> 
>  
> Hi Anselm,
> 
>  
> Welcome!
> 
>  
> A good way of getting used to a list like this one is to wait a little while and observe what kind of messages others send; this will give you a feel for how the list is used. If you're impatient, you can also check out the archives at https://mail.haskell.org/pipermail/ghc-devs/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-devs%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404154244&sdata=w4QIMTGeMQ35bEo4xkOn2rIj8z02iMVje4Ar9AXM22k%3D&reserved=0>.
> 
>  
> As for a feature request: if your feature changes the language GHC accepts (most do), the right place to post is at https://githubcom/ghc-proposals/ghc-proposals <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=ogVVk5kRFXPc81dZ%2FiyGV9FbgQoQUtzazpFGcrAKUXA%3D&reserved=0>. There is a description of how to proceed on that page. Proposals submitted there get debated within the community and then eventually sent to a GHC Steering Committee for a vote on acceptance or rejection. Then, we worry about implementing it. If you have a suggestion that does not change the language GHC accepts, you can post an Issue at https://gitlab.haskell.org/ghc/ghc/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=tg40q%2B9%2BW5KcVzHsPx9oCP7wdw5ipdZCOOdFnzUz3mU%3D&reserved=0>.
> 
>  
> I hope this is helpful!
> 
> Richard
> 
>  
> On Aug 4, 2020, at 8:59 AM, Anselm Schüler (conversations subemail) <conversation at anselmschueler.com <mailto:conversation at anselmschueler.com>> wrote:
> 
>  
> First of all, in general, I’m new to mailing lists (as used for discussions) in general, so a question about that:
> 
> When subscribed to the mailing list, do you get every message, or are some discussions hidden?
> 
>  
> Second of all, I’d like to know what kinds of messages are appropriate here. I’m not familiar with coding compilers or anything of the like, so I’m somewhat afraid of offering unhelpful comments or being just woefully underqualified to participate here.
> 
> For example, I have a feature idea in the back of my mind, which I imagine would be easy to implement (that might be wrong). Is it alright if I submit that here or should I use some other forum?
> 
>  
> Thank you in advance for the answers.
> 
>  
> Anselm Schüler
> 
> www.anselmschueler.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.anselmschueler.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404164244&sdata=WJBJ3P%2BFUnTmVs9Z97DHLat9mHr6vC22l0mQ36nafGc%3D&reserved=0>
> mail at anselmschueler.com <mailto:mail at anselmschueler.com>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ce68e6131af494519061c08d83887d962%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637321503404174237&sdata=9y99aKPjfvm7WIH5Xv9JDlN7TIXdVPJZF%2BvAgbUvBUU%3D&reserved=0>
>  
>  
>  
> _______________________________________________
> 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>
>  
>  
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> 
>  
> 
> --
> 
> brandon s allbery kf8nh
> 
> allbery.b at gmail.com <mailto:allbery.b at gmail.com>
>  
> 
> 
> 
> -- 
> brandon s allbery kf8nh
> allbery.b at gmail.com <mailto:allbery.b at gmail.com>_______________________________________________
> 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/20200804/3291f54e/attachment.html>

From sylvain at haskus.fr  Tue Aug  4 21:37:25 2020
From: sylvain at haskus.fr (Sylvain Henry)
Date: Tue, 4 Aug 2020 23:37:25 +0200
Subject: Using a development snapshot of happy
In-Reply-To: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
References: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
Message-ID: <84093748-8c67-31cb-3377-277dd2e737ec@haskus.fr>

Hi,

For solution b, Happy doesn't have to be a submodule. You can add it to 
hadrian/stack.yaml if you build with stack. See 
https://gitlab.haskell.org/ghc/ghc/-/commit/90e0ab7d80d88463df97bc3514fc89d2ab9fcfca 
where I had to do this.  It may be possible to do the same for Cabal 
with hadrian/cabal.project but I've not tried it.

Cheers,
Sylvain


On 02/08/2020 09:43, Vladislav Zavialov wrote:
> Hi ghc-devs,
>
> I’m working on the unification of parsers for terms and types, and one of the things I’d really like to make use of is a feature I implemented in ‘happy’ in October 2019 (9 months ago):
>
>    https://github.com/simonmar/happy/pull/153
>
> It’s been merged upstream, but there has been no release of ‘happy’, despite repeated requests:
>
>    1. I asked for a release in December: https://github.com/simonmar/happy/issues/164
>    2. Ben asked for a release a month ago: https://github.com/simonmar/happy/issues/168
>
> I see two solutions here:
>
>    a) Find a co-maintainer for ‘happy’ who could make releases more frequently (I understand the current maintainers probably don’t have the time to do it).
>    b) Use a development snapshot of ‘happy’ in GHC
>
> Maybe we need to do both, but one reason I’d like to see (b) in particular happen is that I can imagine introducing more features to ‘happy’ for use in GHC, and it’d be nice not to wait for a release every time. For instance, there are some changes I’d like to make to happy/alex in order to implement #17750
>
> So here are two questions I have:
>
>    1. Are there any objections to this idea?
>    2. If not, could someone more familiar with the build process guide me as to how this should be implemented? Do I add ‘happy’ as a submodule and change something in the ./configure script, or is there more to it? Do I need to modify make/hadrian, and if so, then how?
>
> Thanks,
> - Vlad
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From compl.yue at gmail.com  Thu Aug  6 17:50:17 2020
From: compl.yue at gmail.com (Compl Yue)
Date: Fri, 7 Aug 2020 01:50:17 +0800
Subject: [Haskell-cafe] STM friendly TreeMap (or similar with range scan
 api) ? WAS: Best ways to achieve throughput, for large M:N ratio of STM
 threads, with hot TVar updates?
In-Reply-To: <33DE75B7-F33F-48EC-8D08-825D264F9C78@icloud.com>
References: <4CAE51E9-2720-4C2F-9971-00FABACA35BC@icloud.com>
 <CADnndOrUaAFiT07pa2MWrtOBhG7_SU3vUuk8CHt1w2mxX-dkzQ@mail.gmail.com>
 <74f14ebd-241b-0b4f-03d5-ea130f69a1c6@icloud.com>
 <CAO27hRofs4bgqJt0rAtd0EbwKzJkhFkHn5P=7HXU=9gn5gkoyQ@mail.gmail.com>
 <41fc9d8e-2356-f3a7-6f00-c8a51d3b95f7@icloud.com>
 <CAO27hRoyaC8EAYbvr5ARV45XP1F6=Ja2UC_cqTOj_WEX3Zi_aw@mail.gmail.com>
 <8136052f-8b5c-c31f-7487-d03f6a86a5d3@icloud.com>
 <CAO27hRpGPqddoB9cnNoEg9phJg8gDexE572fOgscCezTS+grog@mail.gmail.com>
 <db403968-ea4b-8b3a-f423-fd95df44f7e7@icloud.com>
 <8d25fa78-9a66-6e24-7771-ba0afa127a04@icloud.com>
 <CAO27hRrWdd+g=1m42QBkPYG-YQ6WFpwRyZy5DfqP4RiqJxxAKQ@mail.gmail.com>
 <D1332AAC-EFA1-4D1B-A2CF-C3C2FACD97EA@icloud.com>
 <CAO27hRoyQgutsz6yhWxpossYOHeREeuMpLALo6d7XskGCQbwfg@mail.gmail.com>
 <VI1PR83MB042996CB7159848F80DEB91EAD700@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <87v9i3g62h.fsf@smart-cactus.org>
 <33DE75B7-F33F-48EC-8D08-825D264F9C78@icloud.com>
Message-ID: <F8D22D57-9153-4FE5-9438-E9F44FAEC6E5@gmail.com>

Hi Devs & Cafe,

I would report back my progress on it, actually I've got a rough conclusion that TL;DR:

> For data-intensive workloads, x86_64 ISA has its cache of CPU chips being a hardware bottleneck, it's very hard to scale up with added number of cores, so long as they share the cache as being in a single chip.

For the details -

I developed a minimal script interpreter for diagnostic purpose, dependent only on libraries bundled with GHC, the source repository is at: https://github.com/complyue/txs <https://github.com/complyue/txs>

I benchmarked on my machine with a single 6-core Xeon E5 CPU chip, for contention-free read/write performance scaling, got numbers at: https://github.com/complyue/txs/blob/master/results/baseline.csv <https://github.com/complyue/txs/blob/master/results/baseline.csv>


conc
thread avg tps
scale
eff
populate
1
1741
1.00
1.00
2
1285
1.48
0.74
3
1028
1.77
0.59
4
843
1.94
0.48
5
696
2.00
0.40
6
600
2.07
0.34





scan
1
1565
1.00
1.00
2
1285
1.64
0.82
3
1018
1.95
0.65
4
843
2.15
0.54
5
696
2.22
0.44
6
586
2.25
0.37






The script is at: https://github.com/complyue/txs/blob/master/scripts/scan.txs <https://github.com/complyue/txs/blob/master/scripts/scan.txs>

GHC cmdl is at: https://github.com/complyue/txs/blob/master/metric.bash <https://github.com/complyue/txs/blob/master/metric.bash>

ghc --make -Wall -threaded -rtsopts -prof -o txs -outputdir . -stubdir . -i../src ../src/Main.hs && (

  ./txs +RTS -N10 -A32m -H256m -qg -I0 -M5g -T -s <../scripts/"${SCRIPT}".txs

)

I intended to use a single Haskell based process to handle meta data about many ndarrays being crunched, acting as a centralized graph database, as it turned out, many clients queued to query/insert meta data against a single database node, will create such high data throughput that just few CPU chips can't handle well, we didn't expect this but apparently we'll have to deploy more machines as for such a database instance, with data partitioned and distributed to more nodes for load balancing. (A single machine with many sockets for CPU thus many NUMA nodes is neither an option for us.) While the flexibility a central graph database would provide, is not currently a crucial requirement of our business,  so we are not interested to further develop this database system.

We currently have CPU intensive workloads handled by some cluster of machines running Python processes (crunching numbers with Numpy and C++ tensors), while some Haskell based number crunching software are still under development, it may turn out some day in the future, that some heavier computation be bound with the db access, effectively creating some CPU intensive workloads for the database functionality, then we'll have the opportunity to dive deeper into the database implementation. And in case more flexibility required in near future, I think I'll tend to implement embedded database instances in those worker processes, in contrast to centralized db servers.

I wonder if ARM servers will have up scaling of data intensive workloads easier, though that's neither a near feasible option for us.

Thanks for everyone that have been helpful!

Best regards,
Compl


> On 2020-07-31, at 22:35, YueCompl via Haskell-Cafe <haskell-cafe at haskell.org> wrote:
> 
> Hi Ben,
> 
> Thanks as always for your great support! And at the moment I'm working on a minimum working example to reproduce the symptoms, I intend to work out a program depends only on libraries bundled with GHC, so it can be easily diagnosed without my complex env,  but so far no reprod yet. I'll come with some piece of code once it can reproduce something.
> 
> Thanks in advance.
> 
> Sincerely,
> Compl
> 
> 
>> On 2020-07-31, at 21:36, Ben Gamari <ben at well-typed.com> wrote:
>> 
>> Simon Peyton Jones via Haskell-Cafe <haskell-cafe at haskell.org> writes:
>> 
>>>> Compl’s problem is (apparently) that execution becomes dominated by
>>>> GC. That doesn’t sound like a constant-factor overhead from TVars, no
>>>> matter how efficient (or otherwise) they are. It sounds more like a
>>>> space leak to me; perhaps you need some strict evaluation or
>>>> something.
>>> 
>>> My point is only: before re-engineering STM it would make sense to get
>>> a much more detailed insight into what is actually happening, and
>>> where the space and time is going. We have tools to do this (heap
>>> profiling, Threadscope, …) but I know they need some skill and insight
>>> to use well. But we don’t have nearly enough insight to draw
>>> meaningful conclusions yet.
>>> 
>>> Maybe someone with experience of performance debugging might feel able
>>> to help Compl?
>>> 
>> Compl,
>> 
>> If you want to discuss the issue feel free to get in touch on IRC. I
>> would be happy to help.
>> 
>> It would be great if we had something of a decision tree for performance
>> tuning of Haskell code in the users guide or Wiki. We have so many tools
>> yet there isn't a comprehensive overview of
>> 
>> 1. what factors might affect which runtime characteristics of your
>>   program
>> 2. which tools can be used to measure which factors
>> 3. how these factors can be improved
>> 
>> Cheers,
>> 
>> - Ben
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

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

From m at tweag.io  Fri Aug  7 13:50:23 2020
From: m at tweag.io (Mathieu Boespflug)
Date: Fri, 07 Aug 2020 13:50:23 +0000
Subject: Question about binary distributions
Message-ID: <kdka6m2p.48f2d1ab-f025-4afa-b76f-dc76e977e444@we.are.superhuman.com>

Hi all,

GHC currently has 3 tier-1 platforms: Linux, macOS and Windows. I'll focus the dicussion below on these three platforms. The binary distributions for Linux and macOS are designed to be unpacked, then the user types ./configure && make install. This is not the case for Windows.

On all platforms it's possible to create "relocatable" installations, such that GHC doesn't really care where it's installed, and commands will still work if the install directory changes location on the filesystem. So my question is, why do we have a ./configure step on Linux and macOS? Why could we not have bindists for all platforms that work like the Windows one? I.e. a binary distribution that you just unpack, in any directory of your choice, without any configuration or installation step.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200807/09423975/attachment.html>

From moritz.angermann at gmail.com  Fri Aug  7 14:22:25 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 7 Aug 2020 22:22:25 +0800
Subject: Question about binary distributions
In-Reply-To: <kdka6m2p.48f2d1ab-f025-4afa-b76f-dc76e977e444@we.are.superhuman.com>
References: <kdka6m2p.48f2d1ab-f025-4afa-b76f-dc76e977e444@we.are.superhuman.com>
Message-ID: <CAKfdd-yvoo7AHncvn5dqma7E-zkdo_19VMiT+Q-8U9HVUM98iQ@mail.gmail.com>

Hi Mathieu,

you can! See http://hackage.mobilehaskell.org/; it's been one of the
design goals I had when I was hacking on hadrian. The whole configure
&& make install shenanigans were just too much.
Initially I wanted to drop that outright, but was convinced that
configure and make install is something distributions want (that
install into different locations) as well as some people who prefer to
install
into ghc into custom locations.

GHC has for a while now had relocatable support on our major
platforms, which means you don't even need that wrapper script anymore
as long as the bin and lib folder are next to each other and you
operating system can find the path of the executable. I'm told AIX
can't if the executable is a symlink.

I'm all for having "unpack and run" bindists with an optional
configure && make install phase for those who want it. As we are
moving over to hadrian as the primary build system I think this should
work,
but might have regressed?

Cheers,
 Moritz

On Fri, Aug 7, 2020 at 9:50 PM Mathieu Boespflug <m at tweag.io> wrote:
>
> Hi all,
>
> GHC currently has 3 tier-1 platforms: Linux, macOS and Windows. I'll focus the dicussion below on these three platforms. The binary distributions for Linux and macOS are designed to be unpacked, then the user types ./configure && make install. This is not the case for Windows.
>
> On all platforms it's possible to create "relocatable" installations, such that GHC doesn't really care where it's installed, and commands will still work if the install directory changes location on the filesystem. So my question is, why do we have a ./configure step on Linux and macOS? Why could we not have bindists for all platforms that work like the Windows one? I.e. a binary distribution that you just unpack, in any directory of your choice, without any configuration or installation step.
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ben at well-typed.com  Fri Aug  7 15:15:11 2020
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 07 Aug 2020 11:15:11 -0400
Subject: Question about binary distributions
In-Reply-To: <kdka6m2p.48f2d1ab-f025-4afa-b76f-dc76e977e444@we.are.superhuman.com>
References: <kdka6m2p.48f2d1ab-f025-4afa-b76f-dc76e977e444@we.are.superhuman.com>
Message-ID: <87h7teebd3.fsf@smart-cactus.org>

"Mathieu Boespflug" <m at tweag.io> writes:

> Hi all,
>
> GHC currently has 3 tier-1 platforms: Linux, macOS and Windows. I'll
> focus the dicussion below on these three platforms. The binary
> distributions for Linux and macOS are designed to be unpacked, then
> the user types ./configure && make install. This is not the case for
> Windows.
>
> On all platforms it's possible to create "relocatable" installations,
> such that GHC doesn't really care where it's installed, and commands
> will still work if the install directory changes location on the
> filesystem. So my question is, why do we have a ./configure step on
> Linux and macOS? Why could we not have bindists for all platforms that
> work like the Windows one? I.e. a binary distribution that you just
> unpack, in any directory of your choice, without any configuration or
> installation step.

There are a few reasons:

 * Relocatable GHC builds have only been supported for only a few
   releases now and only under the Hadrian build system, which is not
   currently used to produce our binary distributions (hopefully this
   will change for 9.2).

 * On Windows we have the luxury of having a very well-controlled
   environment as we rely on essentially nothing from the host
   system. We provide our own mingw toolchain, statically link
   against libc, and have no additional dynamic dependencies.

   By contrast, on Linux we have to deal with a much larger
   configuration space:

    * several linkers, each with their own bugs

    * several C compilers, supporting various subsets of functionality
      and quirks (e.g. some distributions enable -pie by default, others
      do not)

    * various LLVM packaging schemes

   Since it would be quite expensive to probe the toolchain
   characteristics on every compiler invocation, we rather do this once
   in the configure script during bindist installation and package the
   result in the installed `settings` file.

 * On Linux we may have additional dynamic dependencies (e.g. libdw,
   numactl) which we check for during configuration time, lest the user
   be faced with an unsightly linker error if they happen to be missing
   a library.

In principle we could perhaps avoid the need for many of these checks
by creating one binary distribution per operating system distribution.
However, we will first need to move to Hadrian to build our binary
distributions.

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/20200807/d8524ffe/attachment.sig>

From John.Ericson at Obsidian.Systems  Fri Aug  7 15:24:31 2020
From: John.Ericson at Obsidian.Systems (John Cotton Ericson)
Date: Fri, 7 Aug 2020 11:24:31 -0400
Subject: Question about binary distributions
In-Reply-To: <87h7teebd3.fsf@smart-cactus.org>
References: <kdka6m2p.48f2d1ab-f025-4afa-b76f-dc76e977e444@we.are.superhuman.com>
 <87h7teebd3.fsf@smart-cactus.org>
Message-ID: <f8e69e92-a028-f83f-cbca-2d1ed604d842@Obsidian.Systems>

Per https://gitlab.haskell.org/ghc/ghc/issues/17191 I do hope to break 
up our configure script soon.[1] Then the bindist will need not ship the 
"entire" configure script, but just what is necessary to fill in the 
settings file(s) which have that information Ben mentions.

I think that will improve the optics of the situation a bit; for 
example, I don't think the reduced bindist configure script should need 
to worry about directories at all since GHC is relocatable (when built 
by Hadrian).

John

[1]: I will be able to resume work on that once I get to the bottom of 
https://gitlab.haskell.org/ghc/ghc/merge_requests/1102. All help greatly 
appreciated!

On 8/7/20 11:15 AM, Ben Gamari wrote:
> "Mathieu Boespflug" <m at tweag.io> writes:
>
>> Hi all,
>>
>> GHC currently has 3 tier-1 platforms: Linux, macOS and Windows. I'll
>> focus the dicussion below on these three platforms. The binary
>> distributions for Linux and macOS are designed to be unpacked, then
>> the user types ./configure && make install. This is not the case for
>> Windows.
>>
>> On all platforms it's possible to create "relocatable" installations,
>> such that GHC doesn't really care where it's installed, and commands
>> will still work if the install directory changes location on the
>> filesystem. So my question is, why do we have a ./configure step on
>> Linux and macOS? Why could we not have bindists for all platforms that
>> work like the Windows one? I.e. a binary distribution that you just
>> unpack, in any directory of your choice, without any configuration or
>> installation step.
> There are a few reasons:
>
>   * Relocatable GHC builds have only been supported for only a few
>     releases now and only under the Hadrian build system, which is not
>     currently used to produce our binary distributions (hopefully this
>     will change for 9.2).
>
>   * On Windows we have the luxury of having a very well-controlled
>     environment as we rely on essentially nothing from the host
>     system. We provide our own mingw toolchain, statically link
>     against libc, and have no additional dynamic dependencies.
>
>     By contrast, on Linux we have to deal with a much larger
>     configuration space:
>
>      * several linkers, each with their own bugs
>
>      * several C compilers, supporting various subsets of functionality
>        and quirks (e.g. some distributions enable -pie by default, others
>        do not)
>
>      * various LLVM packaging schemes
>
>     Since it would be quite expensive to probe the toolchain
>     characteristics on every compiler invocation, we rather do this once
>     in the configure script during bindist installation and package the
>     result in the installed `settings` file.
>
>   * On Linux we may have additional dynamic dependencies (e.g. libdw,
>     numactl) which we check for during configuration time, lest the user
>     be faced with an unsightly linker error if they happen to be missing
>     a library.
>
> In principle we could perhaps avoid the need for many of these checks
> by creating one binary distribution per operating system distribution.
> However, we will first need to move to Hadrian to build our binary
> distributions.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200807/2e4b662c/attachment.html>

From allbery.b at gmail.com  Fri Aug  7 16:05:44 2020
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 7 Aug 2020 12:05:44 -0400
Subject: Question about binary distributions
In-Reply-To: <f8e69e92-a028-f83f-cbca-2d1ed604d842@Obsidian.Systems>
References: <kdka6m2p.48f2d1ab-f025-4afa-b76f-dc76e977e444@we.are.superhuman.com>
 <87h7teebd3.fsf@smart-cactus.org>
 <f8e69e92-a028-f83f-cbca-2d1ed604d842@Obsidian.Systems>
Message-ID: <CAKFCL4Vpx1ds7KZjAn4q5CAwexPaqMLz3fJmnF20RezLs92kSQ@mail.gmail.com>

It's only relocatable given some assumptions which are violated by
various distributions (AIX was already mentioned; and the bin and lib
directories may not be next to each other with some distributions'
preferred configurations). Basically the configure mechanism gives us
some flexibility not otherwise available, without requiring a full
build from source (which is fairly involved and requires an existing
ghc).

On 8/7/20, John Cotton Ericson <John.Ericson at obsidian.systems> wrote:
> Per https://gitlab.haskell.org/ghc/ghc/issues/17191 I do hope to break
> up our configure script soon.[1] Then the bindist will need not ship the
> "entire" configure script, but just what is necessary to fill in the
> settings file(s) which have that information Ben mentions.
>
> I think that will improve the optics of the situation a bit; for
> example, I don't think the reduced bindist configure script should need
> to worry about directories at all since GHC is relocatable (when built
> by Hadrian).
>
> John
>
> [1]: I will be able to resume work on that once I get to the bottom of
> https://gitlab.haskell.org/ghc/ghc/merge_requests/1102. All help greatly
> appreciated!
>
> On 8/7/20 11:15 AM, Ben Gamari wrote:
>> "Mathieu Boespflug" <m at tweag.io> writes:
>>
>>> Hi all,
>>>
>>> GHC currently has 3 tier-1 platforms: Linux, macOS and Windows. I'll
>>> focus the dicussion below on these three platforms. The binary
>>> distributions for Linux and macOS are designed to be unpacked, then
>>> the user types ./configure && make install. This is not the case for
>>> Windows.
>>>
>>> On all platforms it's possible to create "relocatable" installations,
>>> such that GHC doesn't really care where it's installed, and commands
>>> will still work if the install directory changes location on the
>>> filesystem. So my question is, why do we have a ./configure step on
>>> Linux and macOS? Why could we not have bindists for all platforms that
>>> work like the Windows one? I.e. a binary distribution that you just
>>> unpack, in any directory of your choice, without any configuration or
>>> installation step.
>> There are a few reasons:
>>
>>   * Relocatable GHC builds have only been supported for only a few
>>     releases now and only under the Hadrian build system, which is not
>>     currently used to produce our binary distributions (hopefully this
>>     will change for 9.2).
>>
>>   * On Windows we have the luxury of having a very well-controlled
>>     environment as we rely on essentially nothing from the host
>>     system. We provide our own mingw toolchain, statically link
>>     against libc, and have no additional dynamic dependencies.
>>
>>     By contrast, on Linux we have to deal with a much larger
>>     configuration space:
>>
>>      * several linkers, each with their own bugs
>>
>>      * several C compilers, supporting various subsets of functionality
>>        and quirks (e.g. some distributions enable -pie by default, others
>>        do not)
>>
>>      * various LLVM packaging schemes
>>
>>     Since it would be quite expensive to probe the toolchain
>>     characteristics on every compiler invocation, we rather do this once
>>     in the configure script during bindist installation and package the
>>     result in the installed `settings` file.
>>
>>   * On Linux we may have additional dynamic dependencies (e.g. libdw,
>>     numactl) which we check for during configuration time, lest the user
>>     be faced with an unsightly linker error if they happen to be missing
>>     a library.
>>
>> In principle we could perhaps avoid the need for many of these checks
>> by creating one binary distribution per operating system distribution.
>> However, we will first need to move to Hadrian to build our binary
>> distributions.
>>
>> Cheers,
>>
>> - Ben
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com

From ben at well-typed.com  Sat Aug  8 19:45:08 2020
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 08 Aug 2020 15:45:08 -0400
Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.10.2 released
Message-ID: <874kpcexbz.fsf@smart-cactus.org>


Hello all,

The GHC team is happy to announce the release of GHC 8.10.2. Source
and binary distributions are available at the usual place:

    https://downloads.haskell.org/ghc/8.10.2/

GHC 8.10.2 fixes a number of issues in present in GHC 8.10.1 including:

 * Fixes a bug in process creation on Windows (#17926).

 * Fixes a code generation bug resulting in incorrect code
   generation for foreign calls with complex arguments (#18527)

 * Fixes a bug causing object merging to fail when the lld linker is in
   use (#17962)

 * Introduces a workaround for a Linux kernel bug in the implementation
   of the timerfd mechanism (#18033).

 * Fixes a few specialiser regressions (#17810, #18120) as well
   introduces a variety of miscellaneous specialiser improvements
   (#16473, #17930, #17966)

 * Fixes a potential loss of sharing due to left operator sections (#18151).

 * Fix bootstrapping of GHC with the LLVM backend on x86-64 (#17920).

 * A few important correctness fixes for the low-latency garbage
   collector. Users of `--nonmoving-gc` are strongly encouraged to upgrade
   promptly.

Note that at the moment we still require that macOS Catalina users
exempt the binary distribution from the notarization requirement by
running `xattr -cr .` on the unpacked tree before running `make install`.
This situation will hopefully be improved for GHC 9.0.1 with the
resolution of #17418 [1].

Cheers,

- Ben

[1] https://gitlab.haskell.org/ghc/ghc/issues/17418
-------------- 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/20200808/c00bfa4f/attachment.sig>

From moritz.angermann at gmail.com  Tue Aug 11 02:09:44 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 11 Aug 2020 10:09:44 +0800
Subject: Call for GHC Maintainers
Message-ID: <CAKfdd-zwkTz9B+ZSBaosJ3ZPKS8i4M8ZjSguLPDCiRoVoDQOjw@mail.gmail.com>

Hi there!

As it stands right now, Ben is the one who works tirelessly trying to
cut releases. Not just for the most recent version, but also for
previous versions. Most recently 8.10.2, but we have 9.0 coming up as
well.

I know that there are some people who deeply care for personal or
professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
them have stacks of patches applied, or proprietary extensions. I'd
argue that most of those applied patches are backports of bug fixes
and rarely language features, as language features will break
compatibility (due to ghc, base, and other library versions anyway).

I would therefore like drum up a group of people who will take care
(ideally 2+ per release) of backporting and making minor partch
releases. This does not have to go on forever, but it would take much
needed load off of Ben to focus on what ever happens in ghc HEAD.

So what would this work actually look like? It would consist of
- going through the list of MRs and tagging those which are relevant
for backporting to a certain release.
- backport MRs where the MR does not cleanly apply.
- fixup any test-suite failures.
- agree on a date to cut/make the release.

This is not a permanent commitment. I hope we can attract more people
to the ghc release managers.

I'm looking forward to great many responses. And I'm sure Ben will be
able to help mentor us through cutting the first releases. I'll
volunteer to be part of the 8.6 branch maintainers for now.

Cheers,
 Moritz

PS: There is a slightly related discussion about release cadence and
versions and how other projects deal with this in this ticket:
https://gitlab.haskell.org/ghc/ghc/-/issues/18222

From takenobu.hs at gmail.com  Tue Aug 11 08:45:51 2020
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Tue, 11 Aug 2020 17:45:51 +0900
Subject: Call for GHC Maintainers
In-Reply-To: <CAKfdd-zwkTz9B+ZSBaosJ3ZPKS8i4M8ZjSguLPDCiRoVoDQOjw@mail.gmail.com>
References: <CAKfdd-zwkTz9B+ZSBaosJ3ZPKS8i4M8ZjSguLPDCiRoVoDQOjw@mail.gmail.com>
Message-ID: <CAPB_NvyCjCw6u+V6iMDzKnSMrTMf54_ZtBKc=j814DoESoebrw@mail.gmail.com>

Hi,

I always appreciate maintainers' hard works.

I'd like to support GHC releases and some tasks.
Is there anything that I could do?

PS
My haskell time is limited to nights and weekends, so my works are slow.
(I can't access to haskell community in the day job...)

Regards,
Takenobu

On Tue, Aug 11, 2020 at 11:10 AM Moritz Angermann
<moritz.angermann at gmail.com> wrote:
>
> Hi there!
>
> As it stands right now, Ben is the one who works tirelessly trying to
> cut releases. Not just for the most recent version, but also for
> previous versions. Most recently 8.10.2, but we have 9.0 coming up as
> well.
>
> I know that there are some people who deeply care for personal or
> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
> them have stacks of patches applied, or proprietary extensions. I'd
> argue that most of those applied patches are backports of bug fixes
> and rarely language features, as language features will break
> compatibility (due to ghc, base, and other library versions anyway).
>
> I would therefore like drum up a group of people who will take care
> (ideally 2+ per release) of backporting and making minor partch
> releases. This does not have to go on forever, but it would take much
> needed load off of Ben to focus on what ever happens in ghc HEAD.
>
> So what would this work actually look like? It would consist of
> - going through the list of MRs and tagging those which are relevant
> for backporting to a certain release.
> - backport MRs where the MR does not cleanly apply.
> - fixup any test-suite failures.
> - agree on a date to cut/make the release.
>
> This is not a permanent commitment. I hope we can attract more people
> to the ghc release managers.
>
> I'm looking forward to great many responses. And I'm sure Ben will be
> able to help mentor us through cutting the first releases. I'll
> volunteer to be part of the 8.6 branch maintainers for now.
>
> Cheers,
>  Moritz
>
> PS: There is a slightly related discussion about release cadence and
> versions and how other projects deal with this in this ticket:
> https://gitlab.haskell.org/ghc/ghc/-/issues/18222
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From hvr at gnu.org  Tue Aug 11 06:52:52 2020
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 11 Aug 2020 08:52:52 +0200
Subject: Call for GHC Maintainers
In-Reply-To: <CAKfdd-zwkTz9B+ZSBaosJ3ZPKS8i4M8ZjSguLPDCiRoVoDQOjw@mail.gmail.com>
References: <CAKfdd-zwkTz9B+ZSBaosJ3ZPKS8i4M8ZjSguLPDCiRoVoDQOjw@mail.gmail.com>
Message-ID: <87lfilsmgr.fsf@gnu.org>

Moritz,

Moritz Angermann <moritz.angermann at gmail.com> writes:
> I know that there are some people who deeply care for personal or
> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of

You skipped GHC 8.2 ;-)

In any way, I'd be interested in helping making GHC 8.2.3+ happen!

Cheers,
Herbert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200811/6cb6b630/attachment.sig>

From a.pelenitsyn at gmail.com  Tue Aug 11 15:03:30 2020
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Tue, 11 Aug 2020 11:03:30 -0400
Subject: Call for GHC Maintainers
In-Reply-To: <CAKfdd-zwkTz9B+ZSBaosJ3ZPKS8i4M8ZjSguLPDCiRoVoDQOjw@mail.gmail.com>
References: <CAKfdd-zwkTz9B+ZSBaosJ3ZPKS8i4M8ZjSguLPDCiRoVoDQOjw@mail.gmail.com>
Message-ID: <CAPKAvQXcO0QJrdpTyjeFyqTabXS0n4SQws2=BZea=6UiRqVq1A@mail.gmail.com>

Hello devs,

I may be under-qualified for this sort of task but I’d be happy to pitch in
if you find it useful.

—
Best regards,
Artem Pelenitsyn

On Mon, Aug 10, 2020 at 10:10 PM Moritz Angermann <
moritz.angermann at gmail.com> wrote:

> Hi there!
>
> As it stands right now, Ben is the one who works tirelessly trying to
> cut releases. Not just for the most recent version, but also for
> previous versions. Most recently 8.10.2, but we have 9.0 coming up as
> well.
>
> I know that there are some people who deeply care for personal or
> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
> them have stacks of patches applied, or proprietary extensions. I'd
> argue that most of those applied patches are backports of bug fixes
> and rarely language features, as language features will break
> compatibility (due to ghc, base, and other library versions anyway).
>
> I would therefore like drum up a group of people who will take care
> (ideally 2+ per release) of backporting and making minor partch
> releases. This does not have to go on forever, but it would take much
> needed load off of Ben to focus on what ever happens in ghc HEAD.
>
> So what would this work actually look like? It would consist of
> - going through the list of MRs and tagging those which are relevant
> for backporting to a certain release.
> - backport MRs where the MR does not cleanly apply.
> - fixup any test-suite failures.
> - agree on a date to cut/make the release.
>
> This is not a permanent commitment. I hope we can attract more people
> to the ghc release managers.
>
> I'm looking forward to great many responses. And I'm sure Ben will be
> able to help mentor us through cutting the first releases. I'll
> volunteer to be part of the 8.6 branch maintainers for now.
>
> Cheers,
>  Moritz
>
> PS: There is a slightly related discussion about release cadence and
> versions and how other projects deal with this in this ticket:
> https://gitlab.haskell.org/ghc/ghc/-/issues/18222
> _______________________________________________
> 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/20200811/722a8575/attachment.html>

From saihemanth at gmail.com  Tue Aug 11 15:29:01 2020
From: saihemanth at gmail.com (Hemanth Kapila)
Date: Tue, 11 Aug 2020 20:59:01 +0530
Subject: Call for GHC Maintainers
In-Reply-To: <CAKfdd-zwkTz9B+ZSBaosJ3ZPKS8i4M8ZjSguLPDCiRoVoDQOjw@mail.gmail.com>
References: <CAKfdd-zwkTz9B+ZSBaosJ3ZPKS8i4M8ZjSguLPDCiRoVoDQOjw@mail.gmail.com>
Message-ID: <CANOK7kso5C654muHBw3JOnr6jT=7jUHkJZpgtn2eqrTWLzi0oQ@mail.gmail.com>

Thanks for the note.

I will be happy to pitch in.

Thanks,
Hemanth

On Tue, 11 Aug 2020, 07:40 Moritz Angermann, <moritz.angermann at gmail.com>
wrote:

> Hi there!
>
> As it stands right now, Ben is the one who works tirelessly trying to
> cut releases. Not just for the most recent version, but also for
> previous versions. Most recently 8.10.2, but we have 9.0 coming up as
> well.
>
> I know that there are some people who deeply care for personal or
> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
> them have stacks of patches applied, or proprietary extensions. I'd
> argue that most of those applied patches are backports of bug fixes
> and rarely language features, as language features will break
> compatibility (due to ghc, base, and other library versions anyway).
>
> I would therefore like drum up a group of people who will take care
> (ideally 2+ per release) of backporting and making minor partch
> releases. This does not have to go on forever, but it would take much
> needed load off of Ben to focus on what ever happens in ghc HEAD.
>
> So what would this work actually look like? It would consist of
> - going through the list of MRs and tagging those which are relevant
> for backporting to a certain release.
> - backport MRs where the MR does not cleanly apply.
> - fixup any test-suite failures.
> - agree on a date to cut/make the release.
>
> This is not a permanent commitment. I hope we can attract more people
> to the ghc release managers.
>
> I'm looking forward to great many responses. And I'm sure Ben will be
> able to help mentor us through cutting the first releases. I'll
> volunteer to be part of the 8.6 branch maintainers for now.
>
> Cheers,
>  Moritz
>
> PS: There is a slightly related discussion about release cadence and
> versions and how other projects deal with this in this ticket:
> https://gitlab.haskell.org/ghc/ghc/-/issues/18222
> _______________________________________________
> 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/20200811/085cd7c6/attachment.html>

From marlowsd at gmail.com  Wed Aug 12 11:41:59 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 12 Aug 2020 12:41:59 +0100
Subject: ApplicativeDo needs a bit of love
Message-ID: <CANsrgPLgiJDLOCgOzRqKq714KXDXs+YHq85FpMm-ZUMdVvFtPg@mail.gmail.com>

Folks,

ApplicativeDo does what it does quite well, indeed it's in heavy use doing
what we built it for, and I was pleasantly surprised to see that 12% of
people would even like it to be enabled by default
<https://taylor.fausak.me/2019/11/16/haskell-survey-results/>. But a number
of issues have arisen around it, some stemming from limitations in the
original implementation and others due to interactions with other features
that we didn't consider at the time.

This message is just to point out that I'd be delighted if anyone wanted to
jump on any of these tickets and work on them, as it's unlikely I'll find
the bandwidth to work on them myself. All the tickets are tagged with
ApplicativeDo:

https://gitlab.haskell.org/ghc/ghc/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=ApplicativeDo

Have at it!

Cheers
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200812/1f364a4b/attachment.html>

From moritz.angermann at gmail.com  Sat Aug 15 07:31:56 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 15 Aug 2020 15:31:56 +0800
Subject: Call for GHC Maintainers
In-Reply-To: <CANOK7kso5C654muHBw3JOnr6jT=7jUHkJZpgtn2eqrTWLzi0oQ@mail.gmail.com>
References: <CAKfdd-zwkTz9B+ZSBaosJ3ZPKS8i4M8ZjSguLPDCiRoVoDQOjw@mail.gmail.com>
 <CANOK7kso5C654muHBw3JOnr6jT=7jUHkJZpgtn2eqrTWLzi0oQ@mail.gmail.com>
Message-ID: <CAKfdd-zfgmAiDWELCV0uLsE2+4dd3w5E_R24W09WpPUZhp9+OQ@mail.gmail.com>

Hi there!

Thanks everyone for showing interest. I've started a wiki page here:
https://gitlab.haskell.org/ghc/ghc/-/wikis/ghc-maintainers
Please add yourself to the release you'd like to maintain. I've tried
to come up with a plan on how to actually look at this problem,
and it appears to me that we want a list of Merge Requests that are
considered for backporting, and then see to which GHC we
backport them.  So essentially a matrix with GHC releases / merge
requests, and values being either empty or the commit in which
the MR was backported.

To get the existing matrix we might try to extract this from the git
history? Does anyone have a good idea how to do this properly?
The alternative would be to go through all existing MRs, and check for
backports, which would be quite tedious, and an automated
solution (at least to get the initial matrix would be good?).  In
general I believe there to be value in a matrix of backports for easy
lookup.

Then we'll need a good way to flag new incoming MRs for backports, and
have the release maintainers look at them, and their
applicability/suitability for a given release.

Finally, let's not kid ourselves here, this will require some time
investment, taking ownership and coordination. I don't think we need
to rush releases, but we should make sure that releases are of good quality.

Cheers,
 Moritz

On Tue, Aug 11, 2020 at 11:29 PM Hemanth Kapila <saihemanth at gmail.com> wrote:
>
> Thanks for the note.
>
> I will be happy to pitch in.
>
> Thanks,
> Hemanth
>
> On Tue, 11 Aug 2020, 07:40 Moritz Angermann, <moritz.angermann at gmail.com> wrote:
>>
>> Hi there!
>>
>> As it stands right now, Ben is the one who works tirelessly trying to
>> cut releases. Not just for the most recent version, but also for
>> previous versions. Most recently 8.10.2, but we have 9.0 coming up as
>> well.
>>
>> I know that there are some people who deeply care for personal or
>> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
>> them have stacks of patches applied, or proprietary extensions. I'd
>> argue that most of those applied patches are backports of bug fixes
>> and rarely language features, as language features will break
>> compatibility (due to ghc, base, and other library versions anyway).
>>
>> I would therefore like drum up a group of people who will take care
>> (ideally 2+ per release) of backporting and making minor partch
>> releases. This does not have to go on forever, but it would take much
>> needed load off of Ben to focus on what ever happens in ghc HEAD.
>>
>> So what would this work actually look like? It would consist of
>> - going through the list of MRs and tagging those which are relevant
>> for backporting to a certain release.
>> - backport MRs where the MR does not cleanly apply.
>> - fixup any test-suite failures.
>> - agree on a date to cut/make the release.
>>
>> This is not a permanent commitment. I hope we can attract more people
>> to the ghc release managers.
>>
>> I'm looking forward to great many responses. And I'm sure Ben will be
>> able to help mentor us through cutting the first releases. I'll
>> volunteer to be part of the 8.6 branch maintainers for now.
>>
>> Cheers,
>>  Moritz
>>
>> PS: There is a slightly related discussion about release cadence and
>> versions and how other projects deal with this in this ticket:
>> https://gitlab.haskell.org/ghc/ghc/-/issues/18222
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ben at well-typed.com  Sat Aug 15 13:50:24 2020
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 15 Aug 2020 09:50:24 -0400
Subject: GHC Logo
Message-ID: <87zh6w9fxf.fsf@smart-cactus.org>

Hi everyone,

Recently a sponsor asked for a logo for our project. As far as I know,
GHC doesn't really have a consistent logo; the closest that we have had
is the stylized "GHC" on the top of ghc.haskell.org.

To accomodate the request, I took a few minutes and reworked the
typography of the Thompson-Wheeler Haskell logo for use by GHC. I
couldn't positively identify the typeface used for the "Haskell" text,
but I believe that the extra-bold Cantarell face that I chose in the GHC
variant has a similar feel to the Haskell logo and is free to use.

I've posted the logo on the Wiki for future reference [1]. Feedback is
very much welcome.

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/20200815/c2145237/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ghc-logo.svg
Type: application/octet-stream
Size: 9622 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200815/c2145237/attachment.obj>
-------------- next part --------------

[1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo

From mail at nh2.me  Sat Aug 15 15:28:25 2020
From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=)
Date: Sat, 15 Aug 2020 17:28:25 +0200
Subject: GHC Logo
In-Reply-To: <87zh6w9fxf.fsf@smart-cactus.org>
References: <87zh6w9fxf.fsf@smart-cactus.org>
Message-ID: <dd60d8fd-a349-6049-9cf1-71a6b36f9b10@nh2.me>

Hey Ben,

it may make sense to make a copy of the SVG that has the font turned into paths;
for me it looks different in Firefox, Thunderbird, and eog, probably because I don't have the font installed.
(This is probably also why the logo is cut off for me in some of them).

From ben at well-typed.com  Sat Aug 15 15:41:42 2020
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 15 Aug 2020 11:41:42 -0400
Subject: GHC Logo
In-Reply-To: <dd60d8fd-a349-6049-9cf1-71a6b36f9b10@nh2.me>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <dd60d8fd-a349-6049-9cf1-71a6b36f9b10@nh2.me>
Message-ID: <87mu2vapc9.fsf@smart-cactus.org>

Niklas Hambüchen <mail at nh2.me> writes:

> Hey Ben,
>
> it may make sense to make a copy of the SVG that has the font turned into paths;
> for me it looks different in Firefox, Thunderbird, and eog, probably because I don't have the font installed.
> (This is probably also why the logo is cut off for me in some of them).

Sigh, of course. I've uploaded another version with path-ified text.

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/20200815/95fcb8ee/attachment.sig>

From carter.schonwald at gmail.com  Sat Aug 15 16:52:27 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 15 Aug 2020 12:52:27 -0400
Subject: GHC Logo
In-Reply-To: <87mu2vapc9.fsf@smart-cactus.org>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <dd60d8fd-a349-6049-9cf1-71a6b36f9b10@nh2.me>
 <87mu2vapc9.fsf@smart-cactus.org>
Message-ID: <CAHYVw0xpPsvkCGVtXT7NCJO-X0dBZ4fCicqWhmAfwLSz_TJO5w@mail.gmail.com>

I def like the serif / times new Roman version

On Sat, Aug 15, 2020 at 11:42 AM Ben Gamari <ben at well-typed.com> wrote:

> Niklas Hambüchen <mail at nh2.me> writes:
>
> > Hey Ben,
> >
> > it may make sense to make a copy of the SVG that has the font turned
> into paths;
> > for me it looks different in Firefox, Thunderbird, and eog, probably
> because I don't have the font installed.
> > (This is probably also why the logo is cut off for me in some of them).
>
> Sigh, of course. I've uploaded another version with path-ified text.
>
> Cheers,
>
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200815/173a83af/attachment.html>

From ben at well-typed.com  Sun Aug 16 14:02:34 2020
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 16 Aug 2020 10:02:34 -0400
Subject: GHC Logo
In-Reply-To: <CAHYVw0xpPsvkCGVtXT7NCJO-X0dBZ4fCicqWhmAfwLSz_TJO5w@mail.gmail.com>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <dd60d8fd-a349-6049-9cf1-71a6b36f9b10@nh2.me>
 <87mu2vapc9.fsf@smart-cactus.org>
 <CAHYVw0xpPsvkCGVtXT7NCJO-X0dBZ4fCicqWhmAfwLSz_TJO5w@mail.gmail.com>
Message-ID: <87ft8madu1.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> I def like the serif / times new Roman version
>
I'm not aware of a serif version and in general I would be hesitant to
introduce one given that:

 1. this would break from the precedent set by the current Haskell logo

 2. details like serifs tend not to translate well into small display
    areas

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/20200816/e8e3c72b/attachment.sig>

From merijn at inconsistent.nl  Sun Aug 16 17:39:27 2020
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Sun, 16 Aug 2020 19:39:27 +0200
Subject: GHC Logo
In-Reply-To: <87ft8madu1.fsf@smart-cactus.org>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <dd60d8fd-a349-6049-9cf1-71a6b36f9b10@nh2.me>
 <87mu2vapc9.fsf@smart-cactus.org>
 <CAHYVw0xpPsvkCGVtXT7NCJO-X0dBZ4fCicqWhmAfwLSz_TJO5w@mail.gmail.com>
 <87ft8madu1.fsf@smart-cactus.org>
Message-ID: <CDFAC7D2-07FE-4BB4-AFDA-1E637ECACB9F@inconsistent.nl>



> On 16 Aug 2020, at 16:02, Ben Gamari <ben at well-typed.com> wrote:
> 
> Carter Schonwald <carter.schonwald at gmail.com> writes:
> 
>> I def like the serif / times new Roman version
>> 
> I'm not aware of a serif version and in general I would be hesitant to
> introduce one given that:

The one you send out renders using a serif font for GHC on my system (and, presumably, Carter's).

Cheers,
Merijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200816/41e6776d/attachment.sig>

From allbery.b at gmail.com  Sun Aug 16 17:41:23 2020
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 16 Aug 2020 13:41:23 -0400
Subject: GHC Logo
In-Reply-To: <CDFAC7D2-07FE-4BB4-AFDA-1E637ECACB9F@inconsistent.nl>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <dd60d8fd-a349-6049-9cf1-71a6b36f9b10@nh2.me>
 <87mu2vapc9.fsf@smart-cactus.org>
 <CAHYVw0xpPsvkCGVtXT7NCJO-X0dBZ4fCicqWhmAfwLSz_TJO5w@mail.gmail.com>
 <87ft8madu1.fsf@smart-cactus.org>
 <CDFAC7D2-07FE-4BB4-AFDA-1E637ECACB9F@inconsistent.nl>
Message-ID: <CAKFCL4VCTBQWKPdnyytgUTXA=TXxammieQ5esSgWYEQrdoFjLg@mail.gmail.com>

Sounds like a missing font to me. It rendered sans-serif here, but I have
that set as default.

On Sun, Aug 16, 2020 at 1:39 PM Merijn Verstraaten <merijn at inconsistent.nl>
wrote:

>
>
> > On 16 Aug 2020, at 16:02, Ben Gamari <ben at well-typed.com> wrote:
> >
> > Carter Schonwald <carter.schonwald at gmail.com> writes:
> >
> >> I def like the serif / times new Roman version
> >>
> > I'm not aware of a serif version and in general I would be hesitant to
> > introduce one given that:
>
> The one you send out renders using a serif font for GHC on my system (and,
> presumably, Carter's).
>
> Cheers,
> Merijn
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


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

From ben at well-typed.com  Sun Aug 16 18:30:45 2020
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 16 Aug 2020 14:30:45 -0400
Subject: GHC Logo
In-Reply-To: <CDFAC7D2-07FE-4BB4-AFDA-1E637ECACB9F@inconsistent.nl>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <dd60d8fd-a349-6049-9cf1-71a6b36f9b10@nh2.me>
 <87mu2vapc9.fsf@smart-cactus.org>
 <CAHYVw0xpPsvkCGVtXT7NCJO-X0dBZ4fCicqWhmAfwLSz_TJO5w@mail.gmail.com>
 <87ft8madu1.fsf@smart-cactus.org>
 <CDFAC7D2-07FE-4BB4-AFDA-1E637ECACB9F@inconsistent.nl>
Message-ID: <87bljaa1f1.fsf@smart-cactus.org>

Merijn Verstraaten <merijn at inconsistent.nl> writes:

>> On 16 Aug 2020, at 16:02, Ben Gamari <ben at well-typed.com> wrote:
>> 
>> Carter Schonwald <carter.schonwald at gmail.com> writes:
>> 
>>> I def like the serif / times new Roman version
>>> 
>> I'm not aware of a serif version and in general I would be hesitant to
>> introduce one given that:
>
> The one you send out renders using a serif font for GHC on my system (and, presumably, Carter's).
>
Indeed, sounds like a missing font. The typeface used is Cantarell,
which is certainly a sans-serif face. You will find a version on the
Wiki which has had the text projected to paths.

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/20200816/5569cdd9/attachment.sig>

From moritz.angermann at gmail.com  Mon Aug 17 08:40:06 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 17 Aug 2020 16:40:06 +0800
Subject: The curious case of #367: Infinite loops can hang Concurrent Haskell
Message-ID: <CAKfdd-w7k8GDjgn_YsiCG0MoA=pTB7Nq++w+EYjte1Ms84u-DA@mail.gmail.com>

Hi there!

While working on a NCG, I eventually came across #367[0], which make GHC produce
code that looks similar to this:

```
label:
  [non-branch-instructions]*
  brach-instruction label
```

so essentially an uninterruptible loop. The solution for GHC to
produce code that
can be interrupted is to pass -fno-omit-yields.

So far so good. Out of curiosity, I did add a small piece of code to
detect this to my NCG
to complain if code like the above was generated[1].

Three weeks ago, I kind of maneuvered myself into a memory blow up
corner, and then
life happened, but this weekend I managed to find some time to revert
some memory
blow up and continue working on the NCG.  Turns out I can build a
stage2 "quick" flavour
of the NCG without dynamic support just fine.  I never saw the dead
lock detection code fire.

Now I did leave the test suite running yesterday night, and when
looking through the
test suite results, there were quite a few failure. Curiously a lot of
them were due to
ghc missing dynamic support (doh!).  But also quite a few that failed
due to the deadlock
detection.

T12485, hs_try_putmvar003, ds-wildcard, ds001, read029, T2817, tc011,
tc021, T4524

So, my question then is this: are we fine with ghc generating this
code? Or, if we are not, do we want to figure out if we can eliminate
it? The issue 367 goes into quite a bit of detail why this is tricky
to handle generally.

Or should we add -fno-omit-yields to the test-cases? The ultimate
option is to just turn of the
detection, and I'm fine with doing so. However I'd rather ask if
anyone sees value in detecting
this or not.

Cheers,
 Moritz

--
[0]: https://gitlab.haskell.org/ghc/ghc/-/issues/367
[1]: https://gitlab.haskell.org/ghc/ghc/-/blob/46fba2c91e1c4d23d46fa2d9b18dcd000c80363d/compiler/GHC/CmmToAsm/AArch64/Ppr.hs#L134-159

From simonpj at microsoft.com  Mon Aug 17 09:18:24 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 17 Aug 2020 09:18:24 +0000
Subject: The curious case of #367: Infinite loops can hang Concurrent
 Haskell
In-Reply-To: <CAKfdd-w7k8GDjgn_YsiCG0MoA=pTB7Nq++w+EYjte1Ms84u-DA@mail.gmail.com>
References: <CAKfdd-w7k8GDjgn_YsiCG0MoA=pTB7Nq++w+EYjte1Ms84u-DA@mail.gmail.com>
Message-ID: <VI1PR83MB0429715E0C2541C3CA74F9ACAD5F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Moritz

I'm not getting this.

|  So, my question then is this: are we fine with ghc generating this
|  code? Or, if we are not, do we want to figure out if we can eliminate
|  it?

What exactly is "this code" and "it"?  

You could be asking

* Should we switch off -fomit-yields by default?
* Should we implement -fno-omit-yields in a cleverer way that generates less code?

Or you could be asking something else again.

Your deadlock-detection patch (which is presumably not in GHC) is very special-case: it detects some infinite loops, but only some.   I'm not sure what role it plays in your thinking.

Simon


|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Moritz
|  Angermann
|  Sent: 17 August 2020 09:40
|  To: ghc-devs <ghc-devs at haskell.org>
|  Subject: The curious case of #367: Infinite loops can hang Concurrent
|  Haskell
|  
|  Hi there!
|  
|  While working on a NCG, I eventually came across #367[0], which make GHC
|  produce
|  code that looks similar to this:
|  
|  ```
|  label:
|    [non-branch-instructions]*
|    brach-instruction label
|  ```
|  
|  so essentially an uninterruptible loop. The solution for GHC to
|  produce code that
|  can be interrupted is to pass -fno-omit-yields.
|  
|  So far so good. Out of curiosity, I did add a small piece of code to
|  detect this to my NCG
|  to complain if code like the above was generated[1].
|  
|  Three weeks ago, I kind of maneuvered myself into a memory blow up
|  corner, and then
|  life happened, but this weekend I managed to find some time to revert
|  some memory
|  blow up and continue working on the NCG.  Turns out I can build a
|  stage2 "quick" flavour
|  of the NCG without dynamic support just fine.  I never saw the dead
|  lock detection code fire.
|  
|  Now I did leave the test suite running yesterday night, and when
|  looking through the
|  test suite results, there were quite a few failure. Curiously a lot of
|  them were due to
|  ghc missing dynamic support (doh!).  But also quite a few that failed
|  due to the deadlock
|  detection.
|  
|  T12485, hs_try_putmvar003, ds-wildcard, ds001, read029, T2817, tc011,
|  tc021, T4524
|  
|  So, my question then is this: are we fine with ghc generating this
|  code? Or, if we are not, do we want to figure out if we can eliminate
|  it? The issue 367 goes into quite a bit of detail why this is tricky
|  to handle generally.
|  
|  Or should we add -fno-omit-yields to the test-cases? The ultimate
|  option is to just turn of the
|  detection, and I'm fine with doing so. However I'd rather ask if
|  anyone sees value in detecting
|  this or not.
|  
|  Cheers,
|   Moritz
|  
|  --
|  [0]:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
|  askell.org%2Fghc%2Fghc%2F-
|  %2Fissues%2F367&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e64
|  1e6c16608d842893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504
|  423501799&amp;sdata=KKZYaNgl%2FliDXwfcEqWIosjRjDYt%2FDc9i1sBEfS22mQ%3D&amp
|  ;reserved=0
|  [1]:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
|  askell.org%2Fghc%2Fghc%2F-
|  %2Fblob%2F46fba2c91e1c4d23d46fa2d9b18dcd000c80363d%2Fcompiler%2FGHC%2FCmmT
|  oAsm%2FAArch64%2FPpr.hs%23L134-
|  159&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c16608d84
|  2893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504423501799&am
|  p;sdata=RMXio8BI9tSjWnKK4HSXA3s%2BXNNM7ntk2ftQjmRJxzE%3D&amp;reserved=0
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
|  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c16608d8
|  42893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504423501799&a
|  mp;sdata=8W595qb3lWsqdAeGeFp0T26DsCXzA6ngrCQLKihCXkA%3D&amp;reserved=0

From moritz.angermann at gmail.com  Mon Aug 17 09:29:45 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 17 Aug 2020 17:29:45 +0800
Subject: The curious case of #367: Infinite loops can hang Concurrent
 Haskell
In-Reply-To: <VI1PR83MB0429715E0C2541C3CA74F9ACAD5F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <CAKfdd-w7k8GDjgn_YsiCG0MoA=pTB7Nq++w+EYjte1Ms84u-DA@mail.gmail.com>
 <VI1PR83MB0429715E0C2541C3CA74F9ACAD5F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAKfdd-ywF=sCH4U6YWMM5Az4nZTdhsPnG-6=3O+7ucfsXW_A+A@mail.gmail.com>

Hi Simon,

sure, I could have been a bit clearer:

Code we currently generate is:
```
 _cCO:
        bl _cCO
```

or

```
 _czf:
        mov x17, x18
        bl _czf
```

and the question then becomes, do we want to investigate if we can
a) detect this is dead code
b) remove it in Cmm or higher, or flat out prevent it from being generated.
c) we don't care about producing this code, and hope the linker will
eliminate it.

Cheers,
  Moritz

On Mon, Aug 17, 2020 at 5:18 PM Simon Peyton Jones
<simonpj at microsoft.com> wrote:
>
> Moritz
>
> I'm not getting this.
>
> |  So, my question then is this: are we fine with ghc generating this
> |  code? Or, if we are not, do we want to figure out if we can eliminate
> |  it?
>
> What exactly is "this code" and "it"?
>
> You could be asking
>
> * Should we switch off -fomit-yields by default?
> * Should we implement -fno-omit-yields in a cleverer way that generates less code?
>
> Or you could be asking something else again.
>
> Your deadlock-detection patch (which is presumably not in GHC) is very special-case: it detects some infinite loops, but only some.   I'm not sure what role it plays in your thinking.
>
> Simon
>
>
> |  -----Original Message-----
> |  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Moritz
> |  Angermann
> |  Sent: 17 August 2020 09:40
> |  To: ghc-devs <ghc-devs at haskell.org>
> |  Subject: The curious case of #367: Infinite loops can hang Concurrent
> |  Haskell
> |
> |  Hi there!
> |
> |  While working on a NCG, I eventually came across #367[0], which make GHC
> |  produce
> |  code that looks similar to this:
> |
> |  ```
> |  label:
> |    [non-branch-instructions]*
> |    brach-instruction label
> |  ```
> |
> |  so essentially an uninterruptible loop. The solution for GHC to
> |  produce code that
> |  can be interrupted is to pass -fno-omit-yields.
> |
> |  So far so good. Out of curiosity, I did add a small piece of code to
> |  detect this to my NCG
> |  to complain if code like the above was generated[1].
> |
> |  Three weeks ago, I kind of maneuvered myself into a memory blow up
> |  corner, and then
> |  life happened, but this weekend I managed to find some time to revert
> |  some memory
> |  blow up and continue working on the NCG.  Turns out I can build a
> |  stage2 "quick" flavour
> |  of the NCG without dynamic support just fine.  I never saw the dead
> |  lock detection code fire.
> |
> |  Now I did leave the test suite running yesterday night, and when
> |  looking through the
> |  test suite results, there were quite a few failure. Curiously a lot of
> |  them were due to
> |  ghc missing dynamic support (doh!).  But also quite a few that failed
> |  due to the deadlock
> |  detection.
> |
> |  T12485, hs_try_putmvar003, ds-wildcard, ds001, read029, T2817, tc011,
> |  tc021, T4524
> |
> |  So, my question then is this: are we fine with ghc generating this
> |  code? Or, if we are not, do we want to figure out if we can eliminate
> |  it? The issue 367 goes into quite a bit of detail why this is tricky
> |  to handle generally.
> |
> |  Or should we add -fno-omit-yields to the test-cases? The ultimate
> |  option is to just turn of the
> |  detection, and I'm fine with doing so. However I'd rather ask if
> |  anyone sees value in detecting
> |  this or not.
> |
> |  Cheers,
> |   Moritz
> |
> |  --
> |  [0]:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
> |  askell.org%2Fghc%2Fghc%2F-
> |  %2Fissues%2F367&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e64
> |  1e6c16608d842893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504
> |  423501799&amp;sdata=KKZYaNgl%2FliDXwfcEqWIosjRjDYt%2FDc9i1sBEfS22mQ%3D&amp
> |  ;reserved=0
> |  [1]:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
> |  askell.org%2Fghc%2Fghc%2F-
> |  %2Fblob%2F46fba2c91e1c4d23d46fa2d9b18dcd000c80363d%2Fcompiler%2FGHC%2FCmmT
> |  oAsm%2FAArch64%2FPpr.hs%23L134-
> |  159&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c16608d84
> |  2893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504423501799&am
> |  p;sdata=RMXio8BI9tSjWnKK4HSXA3s%2BXNNM7ntk2ftQjmRJxzE%3D&amp;reserved=0
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> |  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c16608d8
> |  42893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504423501799&a
> |  mp;sdata=8W595qb3lWsqdAeGeFp0T26DsCXzA6ngrCQLKihCXkA%3D&amp;reserved=0

From simonpj at microsoft.com  Mon Aug 17 12:14:37 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 17 Aug 2020 12:14:37 +0000
Subject: The curious case of #367: Infinite loops can hang Concurrent
 Haskell
In-Reply-To: <CAKfdd-ywF=sCH4U6YWMM5Az4nZTdhsPnG-6=3O+7ucfsXW_A+A@mail.gmail.com>
References: <CAKfdd-w7k8GDjgn_YsiCG0MoA=pTB7Nq++w+EYjte1Ms84u-DA@mail.gmail.com>
 <VI1PR83MB0429715E0C2541C3CA74F9ACAD5F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAKfdd-ywF=sCH4U6YWMM5Az4nZTdhsPnG-6=3O+7ucfsXW_A+A@mail.gmail.com>
Message-ID: <PR3PR83MB042783B55D48193A07145435AD5F0@PR3PR83MB0427.EURPRD83.prod.outlook.com>

|  and the question then becomes, do we want to investigate if we can
|  a) detect this is dead code
|  b) remove it in Cmm or higher, or flat out prevent it from being
|  generated.
|  c) we don't care about producing this code, and hope the linker will
|  eliminate it.

I'm still puzzled.  Why do you thing _cCO is dead?  What alternative code are you thinking we might generate?

S

|  -----Original Message-----
|  From: Moritz Angermann <moritz.angermann at gmail.com>
|  Sent: 17 August 2020 10:30
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-devs <ghc-devs at haskell.org>
|  Subject: Re: The curious case of #367: Infinite loops can hang
|  Concurrent Haskell
|  
|  Hi Simon,
|  
|  sure, I could have been a bit clearer:
|  
|  Code we currently generate is:
|  ```
|   _cCO:
|          bl _cCO
|  ```
|  
|  or
|  
|  ```
|   _czf:
|          mov x17, x18
|          bl _czf
|  ```
|  
|  and the question then becomes, do we want to investigate if we can
|  a) detect this is dead code
|  b) remove it in Cmm or higher, or flat out prevent it from being
|  generated.
|  c) we don't care about producing this code, and hope the linker will
|  eliminate it.|  
|  Cheers,
|    Moritz
|  
|  On Mon, Aug 17, 2020 at 5:18 PM Simon Peyton Jones
|  <simonpj at microsoft.com> wrote:
|  >
|  > Moritz
|  >
|  > I'm not getting this.
|  >
|  > |  So, my question then is this: are we fine with ghc generating
|  this
|  > |  code? Or, if we are not, do we want to figure out if we can
|  eliminate
|  > |  it?
|  >
|  > What exactly is "this code" and "it"?
|  >
|  > You could be asking
|  >
|  > * Should we switch off -fomit-yields by default?
|  > * Should we implement -fno-omit-yields in a cleverer way that
|  generates less code?
|  >
|  > Or you could be asking something else again.
|  >
|  > Your deadlock-detection patch (which is presumably not in GHC) is
|  very special-case: it detects some infinite loops, but only some.
|  I'm not sure what role it plays in your thinking.
|  >
|  > Simon
|  >
|  >
|  > |  -----Original Message-----
|  > |  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Moritz
|  > |  Angermann
|  > |  Sent: 17 August 2020 09:40
|  > |  To: ghc-devs <ghc-devs at haskell.org>
|  > |  Subject: The curious case of #367: Infinite loops can hang
|  Concurrent
|  > |  Haskell
|  > |
|  > |  Hi there!
|  > |
|  > |  While working on a NCG, I eventually came across #367[0], which
|  make GHC
|  > |  produce
|  > |  code that looks similar to this:
|  > |
|  > |  ```
|  > |  label:
|  > |    [non-branch-instructions]*
|  > |    brach-instruction label
|  > |  ```
|  > |
|  > |  so essentially an uninterruptible loop. The solution for GHC to
|  > |  produce code that
|  > |  can be interrupted is to pass -fno-omit-yields.
|  > |
|  > |  So far so good. Out of curiosity, I did add a small piece of code
|  to
|  > |  detect this to my NCG
|  > |  to complain if code like the above was generated[1].
|  > |
|  > |  Three weeks ago, I kind of maneuvered myself into a memory blow
|  up
|  > |  corner, and then
|  > |  life happened, but this weekend I managed to find some time to
|  revert
|  > |  some memory
|  > |  blow up and continue working on the NCG.  Turns out I can build a
|  > |  stage2 "quick" flavour
|  > |  of the NCG without dynamic support just fine.  I never saw the
|  dead
|  > |  lock detection code fire.
|  > |
|  > |  Now I did leave the test suite running yesterday night, and when
|  > |  looking through the
|  > |  test suite results, there were quite a few failure. Curiously a
|  lot of
|  > |  them were due to
|  > |  ghc missing dynamic support (doh!).  But also quite a few that
|  failed
|  > |  due to the deadlock
|  > |  detection.
|  > |
|  > |  T12485, hs_try_putmvar003, ds-wildcard, ds001, read029, T2817,
|  tc011,
|  > |  tc021, T4524
|  > |
|  > |  So, my question then is this: are we fine with ghc generating
|  this
|  > |  code? Or, if we are not, do we want to figure out if we can
|  eliminate
|  > |  it? The issue 367 goes into quite a bit of detail why this is
|  tricky
|  > |  to handle generally.
|  > |
|  > |  Or should we add -fno-omit-yields to the test-cases? The ultimate
|  > |  option is to just turn of the
|  > |  detection, and I'm fine with doing so. However I'd rather ask if
|  > |  anyone sees value in detecting
|  > |  this or not.
|  > |
|  > |  Cheers,
|  > |   Moritz
|  > |
|  > |  --
|  > |  [0]:
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  ab.h
|  > |  askell.org%2Fghc%2Fghc%2F-
|  > |
|  %2Fissues%2F367&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead06
|  2e64
|  > |
|  1e6c16608d842893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733
|  2504
|  > |
|  423501799&amp;sdata=KKZYaNgl%2FliDXwfcEqWIosjRjDYt%2FDc9i1sBEfS22mQ%3D
|  &amp
|  > |  ;reserved=0
|  > |  [1]:
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  ab.h
|  > |  askell.org%2Fghc%2Fghc%2F-
|  > |
|  %2Fblob%2F46fba2c91e1c4d23d46fa2d9b18dcd000c80363d%2Fcompiler%2FGHC%2F
|  CmmT
|  > |  oAsm%2FAArch64%2FPpr.hs%23L134-
|  > |
|  159&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c1660
|  8d84
|  > |
|  2893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733250442350179
|  9&am
|  > |
|  p;sdata=RMXio8BI9tSjWnKK4HSXA3s%2BXNNM7ntk2ftQjmRJxzE%3D&amp;reserved=
|  0
|  > |  _______________________________________________
|  > |  ghc-devs mailing list
|  > |  ghc-devs at haskell.org
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
|  hask
|  > |  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  > |
|  devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c166
|  08d8
|  > |
|  42893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373325044235017
|  99&a
|  > |
|  mp;sdata=8W595qb3lWsqdAeGeFp0T26DsCXzA6ngrCQLKihCXkA%3D&amp;reserved=0

From moritz.angermann at gmail.com  Mon Aug 17 12:27:58 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 17 Aug 2020 20:27:58 +0800
Subject: The curious case of #367: Infinite loops can hang Concurrent
 Haskell
In-Reply-To: <PR3PR83MB042783B55D48193A07145435AD5F0@PR3PR83MB0427.EURPRD83.prod.outlook.com>
References: <CAKfdd-w7k8GDjgn_YsiCG0MoA=pTB7Nq++w+EYjte1Ms84u-DA@mail.gmail.com>
 <VI1PR83MB0429715E0C2541C3CA74F9ACAD5F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAKfdd-ywF=sCH4U6YWMM5Az4nZTdhsPnG-6=3O+7ucfsXW_A+A@mail.gmail.com>
 <PR3PR83MB042783B55D48193A07145435AD5F0@PR3PR83MB0427.EURPRD83.prod.outlook.com>
Message-ID: <CAKfdd-ymuDTX=RxZsTo=BFjiqcLod-x_rdg-0rtf2+b3ioOM1g@mail.gmail.com>

On Mon, 17 Aug 2020 at 8:14 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> |  and the question then becomes, do we want to investigate if we can
>
> |  a) detect this is dead code
>
> |  b) remove it in Cmm or higher, or flat out prevent it from being
>
> |  generated.
>
> |  c) we don't care about producing this code, and hope the linker will
>
> |  eliminate it.
>
>
>
> I'm still puzzled.  Why do you thing _cCO is dead?  What alternative code
> are you thinking we might generate?


My question is earlier: why do we generate code that we will never to get
out again? The generated code is effectively: while(true);.

This code does not have to be dead, and there may very well be reasons why
we want to generate an infinite loop that can only be terminated from the
outside. Maybe it’s just my naive expectation that the user more likely did
not want to generate this code.

Once _cCO is entered, there is no way out for the application.

Cheers,
 Moritz


>
>
>
> S
>
>
>
> |  -----Original Message-----
>
> |  From: Moritz Angermann <moritz.angermann at gmail.com>
>
> |  Sent: 17 August 2020 10:30
>
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
>
> |  Cc: ghc-devs <ghc-devs at haskell.org>
>
> |  Subject: Re: The curious case of #367: Infinite loops can hang
>
> |  Concurrent Haskell
>
> |
>
> |  Hi Simon,
>
> |
>
> |  sure, I could have been a bit clearer:
>
> |
>
> |  Code we currently generate is:
>
> |  ```
>
> |   _cCO:
>
> |          bl _cCO
>
> |  ```
>
> |
>
> |  or
>
> |
>
> |  ```
>
> |   _czf:
>
> |          mov x17, x18
>
> |          bl _czf
>
> |  ```
>
> |
>
> |  and the question then becomes, do we want to investigate if we can
>
> |  a) detect this is dead code
>
> |  b) remove it in Cmm or higher, or flat out prevent it from being
>
> |  generated.
>
> |  c) we don't care about producing this code, and hope the linker will
>
> |  eliminate it.|
>
> |  Cheers,
>
> |    Moritz
>
> |
>
> |  On Mon, Aug 17, 2020 at 5:18 PM Simon Peyton Jones
>
> |  <simonpj at microsoft.com> wrote:
>
> |  >
>
> |  > Moritz
>
> |  >
>
> |  > I'm not getting this.
>
> |  >
>
> |  > |  So, my question then is this: are we fine with ghc generating
>
> |  this
>
> |  > |  code? Or, if we are not, do we want to figure out if we can
>
> |  eliminate
>
> |  > |  it?
>
> |  >
>
> |  > What exactly is "this code" and "it"?
>
> |  >
>
> |  > You could be asking
>
> |  >
>
> |  > * Should we switch off -fomit-yields by default?
>
> |  > * Should we implement -fno-omit-yields in a cleverer way that
>
> |  generates less code?
>
> |  >
>
> |  > Or you could be asking something else again.
>
> |  >
>
> |  > Your deadlock-detection patch (which is presumably not in GHC) is
>
> |  very special-case: it detects some infinite loops, but only some.
>
> |  I'm not sure what role it plays in your thinking.
>
> |  >
>
> |  > Simon
>
> |  >
>
> |  >
>
> |  > |  -----Original Message-----
>
> |  > |  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Moritz
>
> |  > |  Angermann
>
> |  > |  Sent: 17 August 2020 09:40
>
> |  > |  To: ghc-devs <ghc-devs at haskell.org>
>
> |  > |  Subject: The curious case of #367: Infinite loops can hang
>
> |  Concurrent
>
> |  > |  Haskell
>
> |  > |
>
> |  > |  Hi there!
>
> |  > |
>
> |  > |  While working on a NCG, I eventually came across #367[0], which
>
> |  make GHC
>
> |  > |  produce
>
> |  > |  code that looks similar to this:
>
> |  > |
>
> |  > |  ```
>
> |  > |  label:
>
> |  > |    [non-branch-instructions]*
>
> |  > |    brach-instruction label
>
> |  > |  ```
>
> |  > |
>
> |  > |  so essentially an uninterruptible loop. The solution for GHC to
>
> |  > |  produce code that
>
> |  > |  can be interrupted is to pass -fno-omit-yields.
>
> |  > |
>
> |  > |  So far so good. Out of curiosity, I did add a small piece of code
>
> |  to
>
> |  > |  detect this to my NCG
>
> |  > |  to complain if code like the above was generated[1].
>
> |  > |
>
> |  > |  Three weeks ago, I kind of maneuvered myself into a memory blow
>
> |  up
>
> |  > |  corner, and then
>
> |  > |  life happened, but this weekend I managed to find some time to
>
> |  revert
>
> |  > |  some memory
>
> |  > |  blow up and continue working on the NCG.  Turns out I can build a
>
> |  > |  stage2 "quick" flavour
>
> |  > |  of the NCG without dynamic support just fine.  I never saw the
>
> |  dead
>
> |  > |  lock detection code fire.
>
> |  > |
>
> |  > |  Now I did leave the test suite running yesterday night, and when
>
> |  > |  looking through the
>
> |  > |  test suite results, there were quite a few failure. Curiously a
>
> |  lot of
>
> |  > |  them were due to
>
> |  > |  ghc missing dynamic support (doh!).  But also quite a few that
>
> |  failed
>
> |  > |  due to the deadlock
>
> |  > |  detection.
>
> |  > |
>
> |  > |  T12485, hs_try_putmvar003, ds-wildcard, ds001, read029, T2817,
>
> |  tc011,
>
> |  > |  tc021, T4524
>
> |  > |
>
> |  > |  So, my question then is this: are we fine with ghc generating
>
> |  this
>
> |  > |  code? Or, if we are not, do we want to figure out if we can
>
> |  eliminate
>
> |  > |  it? The issue 367 goes into quite a bit of detail why this is
>
> |  tricky
>
> |  > |  to handle generally.
>
> |  > |
>
> |  > |  Or should we add -fno-omit-yields to the test-cases? The ultimate
>
> |  > |  option is to just turn of the
>
> |  > |  detection, and I'm fine with doing so. However I'd rather ask if
>
> |  > |  anyone sees value in detecting
>
> |  > |  this or not.
>
> |  > |
>
> |  > |  Cheers,
>
> |  > |   Moritz
>
> |  > |
>
> |  > |  --
>
> |  > |  [0]:
>
> |  > |
>
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
>
> |  ab.h
>
> |  > |  askell.org%2Fghc%2Fghc%2F-
>
> |  > |
>
> |  %2Fissues%2F367&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead06
>
> |  2e64
>
> |  > |
>
> |  1e6c16608d842893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733
>
> |  2504
>
> |  > |
>
> |  423501799&amp;sdata=KKZYaNgl%2FliDXwfcEqWIosjRjDYt%2FDc9i1sBEfS22mQ%3D
>
> |  &amp
>
> |  > |  ;reserved=0
>
> |  > |  [1]:
>
> |  > |
>
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
>
> |  ab.h
>
> |  > |  askell.org%2Fghc%2Fghc%2F-
>
> |  > |
>
> |  %2Fblob%2F46fba2c91e1c4d23d46fa2d9b18dcd000c80363d%2Fcompiler%2FGHC%2F
>
> |  CmmT
>
> |  > |  oAsm%2FAArch64%2FPpr.hs%23L134-
>
> |  > |
>
> |  159&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c1660
>
> |  8d84
>
> |  > |
>
> |  2893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733250442350179
>
> |  9&am
>
> |  > |
>
> |  p;sdata=RMXio8BI9tSjWnKK4HSXA3s%2BXNNM7ntk2ftQjmRJxzE%3D&amp;reserved=
>
> |  0
>
> |  > |  _______________________________________________
>
> |  > |  ghc-devs mailing list
>
> |  > |  ghc-devs at haskell.org
>
> |  > |
>
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
>
> |  hask
>
> |  > |  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
>
> |  > |
>
> |  devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c166
>
> |  08d8
>
> |  > |
>
> |  42893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373325044235017
>
> |  99&a
>
> |  > |
>
> |  mp;sdata=8W595qb3lWsqdAeGeFp0T26DsCXzA6ngrCQLKihCXkA%3D&amp;reserved=0
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200817/2594ff1d/attachment.html>

From simonpj at microsoft.com  Mon Aug 17 12:38:46 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 17 Aug 2020 12:38:46 +0000
Subject: The curious case of #367: Infinite loops can hang Concurrent
 Haskell
In-Reply-To: <CAKfdd-ymuDTX=RxZsTo=BFjiqcLod-x_rdg-0rtf2+b3ioOM1g@mail.gmail.com>
References: <CAKfdd-w7k8GDjgn_YsiCG0MoA=pTB7Nq++w+EYjte1Ms84u-DA@mail.gmail.com>
 <VI1PR83MB0429715E0C2541C3CA74F9ACAD5F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAKfdd-ywF=sCH4U6YWMM5Az4nZTdhsPnG-6=3O+7ucfsXW_A+A@mail.gmail.com>
 <PR3PR83MB042783B55D48193A07145435AD5F0@PR3PR83MB0427.EURPRD83.prod.outlook.com>
 <CAKfdd-ymuDTX=RxZsTo=BFjiqcLod-x_rdg-0rtf2+b3ioOM1g@mail.gmail.com>
Message-ID: <PR3PR83MB042765D57C1ED89395E11A3FAD5F0@PR3PR83MB0427.EURPRD83.prod.outlook.com>

My question is earlier: why do we generate code that we will never to get out again?

Ah, well, if you say, for example
                f x = f x
then it seems reasonably to generate an infinite loop.   I don’t know if that’s what’s happening here, but it seems reasonable in principle.

I’m unsure about what you are proposing to change.

Simon

From: Moritz Angermann <moritz.angermann at gmail.com>
Sent: 17 August 2020 13:28
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Re: The curious case of #367: Infinite loops can hang Concurrent Haskell



On Mon, 17 Aug 2020 at 8:14 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
|  and the question then becomes, do we want to investigate if we can

|  a) detect this is dead code

|  b) remove it in Cmm or higher, or flat out prevent it from being

|  generated.

|  c) we don't care about producing this code, and hope the linker will

|  eliminate it.



I'm still puzzled.  Why do you thing _cCO is dead?  What alternative code are you thinking we might generate?

My question is earlier: why do we generate code that we will never to get out again? The generated code is effectively: while(true);.

This code does not have to be dead, and there may very well be reasons why we want to generate an infinite loop that can only be terminated from the outside. Maybe it’s just my naive expectation that the user more likely did not want to generate this code.

Once _cCO is entered, there is no way out for the application.

Cheers,
 Moritz





S



|  -----Original Message-----

|  From: Moritz Angermann <moritz.angermann at gmail.com<mailto:moritz.angermann at gmail.com>>

|  Sent: 17 August 2020 10:30

|  To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>

|  Cc: ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>

|  Subject: Re: The curious case of #367: Infinite loops can hang

|  Concurrent Haskell

|

|  Hi Simon,

|

|  sure, I could have been a bit clearer:

|

|  Code we currently generate is:

|  ```

|   _cCO:

|          bl _cCO

|  ```

|

|  or

|

|  ```

|   _czf:

|          mov x17, x18

|          bl _czf

|  ```

|

|  and the question then becomes, do we want to investigate if we can

|  a) detect this is dead code

|  b) remove it in Cmm or higher, or flat out prevent it from being

|  generated.

|  c) we don't care about producing this code, and hope the linker will

|  eliminate it.|

|  Cheers,

|    Moritz

|

|  On Mon, Aug 17, 2020 at 5:18 PM Simon Peyton Jones

|  <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

|  >

|  > Moritz

|  >

|  > I'm not getting this.

|  >

|  > |  So, my question then is this: are we fine with ghc generating

|  this

|  > |  code? Or, if we are not, do we want to figure out if we can

|  eliminate

|  > |  it?

|  >

|  > What exactly is "this code" and "it"?

|  >

|  > You could be asking

|  >

|  > * Should we switch off -fomit-yields by default?

|  > * Should we implement -fno-omit-yields in a cleverer way that

|  generates less code?

|  >

|  > Or you could be asking something else again.

|  >

|  > Your deadlock-detection patch (which is presumably not in GHC) is

|  very special-case: it detects some infinite loops, but only some.

|  I'm not sure what role it plays in your thinking.

|  >

|  > Simon

|  >

|  >

|  > |  -----Original Message-----

|  > |  From: ghc-devs <ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>> On Behalf Of Moritz

|  > |  Angermann

|  > |  Sent: 17 August 2020 09:40

|  > |  To: ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>

|  > |  Subject: The curious case of #367: Infinite loops can hang

|  Concurrent

|  > |  Haskell

|  > |

|  > |  Hi there!

|  > |

|  > |  While working on a NCG, I eventually came across #367[0], which

|  make GHC

|  > |  produce

|  > |  code that looks similar to this:

|  > |

|  > |  ```

|  > |  label:

|  > |    [non-branch-instructions]*

|  > |    brach-instruction label

|  > |  ```

|  > |

|  > |  so essentially an uninterruptible loop. The solution for GHC to

|  > |  produce code that

|  > |  can be interrupted is to pass -fno-omit-yields.

|  > |

|  > |  So far so good. Out of curiosity, I did add a small piece of code

|  to

|  > |  detect this to my NCG

|  > |  to complain if code like the above was generated[1].

|  > |

|  > |  Three weeks ago, I kind of maneuvered myself into a memory blow

|  up

|  > |  corner, and then

|  > |  life happened, but this weekend I managed to find some time to

|  revert

|  > |  some memory

|  > |  blow up and continue working on the NCG.  Turns out I can build a

|  > |  stage2 "quick" flavour

|  > |  of the NCG without dynamic support just fine.  I never saw the

|  dead

|  > |  lock detection code fire.

|  > |

|  > |  Now I did leave the test suite running yesterday night, and when

|  > |  looking through the

|  > |  test suite results, there were quite a few failure. Curiously a

|  lot of

|  > |  them were due to

|  > |  ghc missing dynamic support (doh!).  But also quite a few that

|  failed

|  > |  due to the deadlock

|  > |  detection.

|  > |

|  > |  T12485, hs_try_putmvar003, ds-wildcard, ds001, read029, T2817,

|  tc011,

|  > |  tc021, T4524

|  > |

|  > |  So, my question then is this: are we fine with ghc generating

|  this

|  > |  code? Or, if we are not, do we want to figure out if we can

|  eliminate

|  > |  it? The issue 367 goes into quite a bit of detail why this is

|  tricky

|  > |  to handle generally.

|  > |

|  > |  Or should we add -fno-omit-yields to the test-cases? The ultimate

|  > |  option is to just turn of the

|  > |  detection, and I'm fine with doing so. However I'd rather ask if

|  > |  anyone sees value in detecting

|  > |  this or not.

|  > |

|  > |  Cheers,

|  > |   Moritz

|  > |

|  > |  --

|  > |  [0]:

|  > |

|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl

|  ab.h

|  > |  askell.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Faskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C9a5a96b91e34458dae1d08d842a9016a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332640933766799&sdata=1AdfLREUvuB5p3h6mfJjnVSGL0VhfSZKEP3p%2FE%2BduuM%3D&reserved=0>%2Fghc%2Fghc%2F-

|  > |

|  %2Fissues%2F367&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C9a5a96b91e34458dae1d08d842a9016a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332640933771794&sdata=Rl8Mn93AwVKEFqLSjblQqzA5tWlCodWkBPtDfMFEwEc%3D&reserved=0>%7C06a6ead06

|  2e64

|  > |

|  1e6c16608d842893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733

|  2504

|  > |

|  423501799&amp;sdata=KKZYaNgl%2FliDXwfcEqWIosjRjDYt%2FDc9i1sBEfS22mQ%3D

|  &amp

|  > |  ;reserved=0

|  > |  [1]:

|  > |

|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl

|  ab.h

|  > |  askell.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Faskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C9a5a96b91e34458dae1d08d842a9016a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332640933776794&sdata=7AL8DozHHcbu6%2BGyHo2Cxh6pkBnd%2FNgn8%2FUxhwq4kR0%3D&reserved=0>%2Fghc%2Fghc%2F-

|  > |

|  %2Fblob%2F46fba2c91e1c4d23d46fa2d9b18dcd000c80363d%2Fcompiler%2FGHC%2F

|  CmmT

|  > |  oAsm%2FAArch64%2FPpr.hs%23L134-

|  > |

|  159&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C9a5a96b91e34458dae1d08d842a9016a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332640933786789&sdata=MAEnEV%2B2YTStXo5mxNvtgsAJadQzPF7B4WWf9PdLWkE%3D&reserved=0>%7C06a6ead062e641e6c1660

|  8d84

|  > |

|  2893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733250442350179

|  9&am

|  > |

|  p;sdata=RMXio8BI9tSjWnKK4HSXA3s%2BXNNM7ntk2ftQjmRJxzE%3D&amp;reserved=

|  0

|  > |  _______________________________________________

|  > |  ghc-devs mailing list

|  > |  ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>

|  > |

|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.

|  hask

|  > |  ell.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C9a5a96b91e34458dae1d08d842a9016a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332640933791786&sdata=Przw0UpM9RQ2v7WqQmGDW8pOoc5Fzhdvn3dxDt3eB%2BQ%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-

|  > |

|  devs&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C9a5a96b91e34458dae1d08d842a9016a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332640933796784&sdata=L2MhSrgu5Izrv45PU0qk5L9K4sw8%2B2t8ekTCuaC1LFA%3D&reserved=0>%7C06a6ead062e641e6c166

|  08d8

|  > |

|  42893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373325044235017

|  99&a

|  > |

|  mp;sdata=8W595qb3lWsqdAeGeFp0T26DsCXzA6ngrCQLKihCXkA%3D&amp;reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200817/58c6c722/attachment.html>

From moritz.angermann at gmail.com  Mon Aug 17 12:59:45 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 17 Aug 2020 20:59:45 +0800
Subject: The curious case of #367: Infinite loops can hang Concurrent
 Haskell
In-Reply-To: <PR3PR83MB042765D57C1ED89395E11A3FAD5F0@PR3PR83MB0427.EURPRD83.prod.outlook.com>
References: <CAKfdd-w7k8GDjgn_YsiCG0MoA=pTB7Nq++w+EYjte1Ms84u-DA@mail.gmail.com>
 <VI1PR83MB0429715E0C2541C3CA74F9ACAD5F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAKfdd-ywF=sCH4U6YWMM5Az4nZTdhsPnG-6=3O+7ucfsXW_A+A@mail.gmail.com>
 <PR3PR83MB042783B55D48193A07145435AD5F0@PR3PR83MB0427.EURPRD83.prod.outlook.com>
 <CAKfdd-ymuDTX=RxZsTo=BFjiqcLod-x_rdg-0rtf2+b3ioOM1g@mail.gmail.com>
 <PR3PR83MB042765D57C1ED89395E11A3FAD5F0@PR3PR83MB0427.EURPRD83.prod.outlook.com>
Message-ID: <CAKfdd-x30sV=hk6_Bu_01prKxyfhtQPpyuDMEOKLwxJFtiUz_w@mail.gmail.com>

I'll investigate why we end up generating the loops, and will report
back if I find anything that looks awfully off. I don't dispute that
there might be legitimate reasons to generate code like this.  From a
user perspective I'd however be grateful if the compiler warns
me about this. Maybe it was my intention, but maybe it wasn't?  Of
course as this might only catch a subset of potential infinite loops
it's not a comprehensive check.

I'll report back if I find anything in the tests that looks off.
Otherwise assume the tests do indeed intend to generate infinite
loops.

Cheers,
 Moritz

On Mon, Aug 17, 2020 at 8:38 PM Simon Peyton Jones
<simonpj at microsoft.com> wrote:
>
> My question is earlier: why do we generate code that we will never to get out again?
>
>
>
> Ah, well, if you say, for example
>
>                 f x = f x
>
> then it seems reasonably to generate an infinite loop.   I don’t know if that’s what’s happening here, but it seems reasonable in principle.
>
>
>
> I’m unsure about what you are proposing to change.
>
>
> Simon
>
>
>
> From: Moritz Angermann <moritz.angermann at gmail.com>
> Sent: 17 August 2020 13:28
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: ghc-devs <ghc-devs at haskell.org>
> Subject: Re: The curious case of #367: Infinite loops can hang Concurrent Haskell
>
>
>
>
>
>
>
> On Mon, 17 Aug 2020 at 8:14 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>
> |  and the question then becomes, do we want to investigate if we can
>
> |  a) detect this is dead code
>
> |  b) remove it in Cmm or higher, or flat out prevent it from being
>
> |  generated.
>
> |  c) we don't care about producing this code, and hope the linker will
>
> |  eliminate it.
>
>
>
> I'm still puzzled.  Why do you thing _cCO is dead?  What alternative code are you thinking we might generate?
>
>
>
> My question is earlier: why do we generate code that we will never to get out again? The generated code is effectively: while(true);.
>
>
>
> This code does not have to be dead, and there may very well be reasons why we want to generate an infinite loop that can only be terminated from the outside. Maybe it’s just my naive expectation that the user more likely did not want to generate this code.
>
>
>
> Once _cCO is entered, there is no way out for the application.
>
>
>
> Cheers,
>
>  Moritz
>
>
>
>
>
>
>
> S
>
>
>
> |  -----Original Message-----
>
> |  From: Moritz Angermann <moritz.angermann at gmail.com>
>
> |  Sent: 17 August 2020 10:30
>
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
>
> |  Cc: ghc-devs <ghc-devs at haskell.org>
>
> |  Subject: Re: The curious case of #367: Infinite loops can hang
>
> |  Concurrent Haskell
>
> |
>
> |  Hi Simon,
>
> |
>
> |  sure, I could have been a bit clearer:
>
> |
>
> |  Code we currently generate is:
>
> |  ```
>
> |   _cCO:
>
> |          bl _cCO
>
> |  ```
>
> |
>
> |  or
>
> |
>
> |  ```
>
> |   _czf:
>
> |          mov x17, x18
>
> |          bl _czf
>
> |  ```
>
> |
>
> |  and the question then becomes, do we want to investigate if we can
>
> |  a) detect this is dead code
>
> |  b) remove it in Cmm or higher, or flat out prevent it from being
>
> |  generated.
>
> |  c) we don't care about producing this code, and hope the linker will
>
> |  eliminate it.|
>
> |  Cheers,
>
> |    Moritz
>
> |
>
> |  On Mon, Aug 17, 2020 at 5:18 PM Simon Peyton Jones
>
> |  <simonpj at microsoft.com> wrote:
>
> |  >
>
> |  > Moritz
>
> |  >
>
> |  > I'm not getting this.
>
> |  >
>
> |  > |  So, my question then is this: are we fine with ghc generating
>
> |  this
>
> |  > |  code? Or, if we are not, do we want to figure out if we can
>
> |  eliminate
>
> |  > |  it?
>
> |  >
>
> |  > What exactly is "this code" and "it"?
>
> |  >
>
> |  > You could be asking
>
> |  >
>
> |  > * Should we switch off -fomit-yields by default?
>
> |  > * Should we implement -fno-omit-yields in a cleverer way that
>
> |  generates less code?
>
> |  >
>
> |  > Or you could be asking something else again.
>
> |  >
>
> |  > Your deadlock-detection patch (which is presumably not in GHC) is
>
> |  very special-case: it detects some infinite loops, but only some.
>
> |  I'm not sure what role it plays in your thinking.
>
> |  >
>
> |  > Simon
>
> |  >
>
> |  >
>
> |  > |  -----Original Message-----
>
> |  > |  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Moritz
>
> |  > |  Angermann
>
> |  > |  Sent: 17 August 2020 09:40
>
> |  > |  To: ghc-devs <ghc-devs at haskell.org>
>
> |  > |  Subject: The curious case of #367: Infinite loops can hang
>
> |  Concurrent
>
> |  > |  Haskell
>
> |  > |
>
> |  > |  Hi there!
>
> |  > |
>
> |  > |  While working on a NCG, I eventually came across #367[0], which
>
> |  make GHC
>
> |  > |  produce
>
> |  > |  code that looks similar to this:
>
> |  > |
>
> |  > |  ```
>
> |  > |  label:
>
> |  > |    [non-branch-instructions]*
>
> |  > |    brach-instruction label
>
> |  > |  ```
>
> |  > |
>
> |  > |  so essentially an uninterruptible loop. The solution for GHC to
>
> |  > |  produce code that
>
> |  > |  can be interrupted is to pass -fno-omit-yields.
>
> |  > |
>
> |  > |  So far so good. Out of curiosity, I did add a small piece of code
>
> |  to
>
> |  > |  detect this to my NCG
>
> |  > |  to complain if code like the above was generated[1].
>
> |  > |
>
> |  > |  Three weeks ago, I kind of maneuvered myself into a memory blow
>
> |  up
>
> |  > |  corner, and then
>
> |  > |  life happened, but this weekend I managed to find some time to
>
> |  revert
>
> |  > |  some memory
>
> |  > |  blow up and continue working on the NCG.  Turns out I can build a
>
> |  > |  stage2 "quick" flavour
>
> |  > |  of the NCG without dynamic support just fine.  I never saw the
>
> |  dead
>
> |  > |  lock detection code fire.
>
> |  > |
>
> |  > |  Now I did leave the test suite running yesterday night, and when
>
> |  > |  looking through the
>
> |  > |  test suite results, there were quite a few failure. Curiously a
>
> |  lot of
>
> |  > |  them were due to
>
> |  > |  ghc missing dynamic support (doh!).  But also quite a few that
>
> |  failed
>
> |  > |  due to the deadlock
>
> |  > |  detection.
>
> |  > |
>
> |  > |  T12485, hs_try_putmvar003, ds-wildcard, ds001, read029, T2817,
>
> |  tc011,
>
> |  > |  tc021, T4524
>
> |  > |
>
> |  > |  So, my question then is this: are we fine with ghc generating
>
> |  this
>
> |  > |  code? Or, if we are not, do we want to figure out if we can
>
> |  eliminate
>
> |  > |  it? The issue 367 goes into quite a bit of detail why this is
>
> |  tricky
>
> |  > |  to handle generally.
>
> |  > |
>
> |  > |  Or should we add -fno-omit-yields to the test-cases? The ultimate
>
> |  > |  option is to just turn of the
>
> |  > |  detection, and I'm fine with doing so. However I'd rather ask if
>
> |  > |  anyone sees value in detecting
>
> |  > |  this or not.
>
> |  > |
>
> |  > |  Cheers,
>
> |  > |   Moritz
>
> |  > |
>
> |  > |  --
>
> |  > |  [0]:
>
> |  > |
>
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
>
> |  ab.h
>
> |  > |  askell.org%2Fghc%2Fghc%2F-
>
> |  > |
>
> |  %2Fissues%2F367&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead06
>
> |  2e64
>
> |  > |
>
> |  1e6c16608d842893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733
>
> |  2504
>
> |  > |
>
> |  423501799&amp;sdata=KKZYaNgl%2FliDXwfcEqWIosjRjDYt%2FDc9i1sBEfS22mQ%3D
>
> |  &amp
>
> |  > |  ;reserved=0
>
> |  > |  [1]:
>
> |  > |
>
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
>
> |  ab.h
>
> |  > |  askell.org%2Fghc%2Fghc%2F-
>
> |  > |
>
> |  %2Fblob%2F46fba2c91e1c4d23d46fa2d9b18dcd000c80363d%2Fcompiler%2FGHC%2F
>
> |  CmmT
>
> |  > |  oAsm%2FAArch64%2FPpr.hs%23L134-
>
> |  > |
>
> |  159&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c1660
>
> |  8d84
>
> |  > |
>
> |  2893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733250442350179
>
> |  9&am
>
> |  > |
>
> |  p;sdata=RMXio8BI9tSjWnKK4HSXA3s%2BXNNM7ntk2ftQjmRJxzE%3D&amp;reserved=
>
> |  0
>
> |  > |  _______________________________________________
>
> |  > |  ghc-devs mailing list
>
> |  > |  ghc-devs at haskell.org
>
> |  > |
>
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
>
> |  hask
>
> |  > |  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
>
> |  > |
>
> |  devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c166
>
> |  08d8
>
> |  > |
>
> |  42893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373325044235017
>
> |  99&a
>
> |  > |
>
> |  mp;sdata=8W595qb3lWsqdAeGeFp0T26DsCXzA6ngrCQLKihCXkA%3D&amp;reserved=0

From moritz.angermann at gmail.com  Tue Aug 18 09:03:22 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 18 Aug 2020 17:03:22 +0800
Subject: Call for GHC Maintainers
In-Reply-To: <CAKfdd-zfgmAiDWELCV0uLsE2+4dd3w5E_R24W09WpPUZhp9+OQ@mail.gmail.com>
References: <CAKfdd-zwkTz9B+ZSBaosJ3ZPKS8i4M8ZjSguLPDCiRoVoDQOjw@mail.gmail.com>
 <CANOK7kso5C654muHBw3JOnr6jT=7jUHkJZpgtn2eqrTWLzi0oQ@mail.gmail.com>
 <CAKfdd-zfgmAiDWELCV0uLsE2+4dd3w5E_R24W09WpPUZhp9+OQ@mail.gmail.com>
Message-ID: <CAKfdd-zZ9UxuWz7JQPJzOHHf2jXbpPscSSULeZ3tMLu8=wapUQ@mail.gmail.com>

Hi there!

So a few more discussions have come up.  And they have mainly centered
around the question of quality assurance.  Cutting GHC releases is time
consuming and not trivial.  And those people would need to take ownership
of those releases and stand by them.  How do we ensure that backports do
not inadvertently break working compiler?  I'm completely against preventing
new contributors to help with making releases on the ground that things can
go wrong.  This would inevitably just end up preventing people form even
trying, and how do you get good at something if you can't even try to get
good
at it?

So the question then is: what can we do to improve/ensure quality of
releases?
We certainly have the test-suite, but that might have holes, and
backporting the
test-suite will only work so far. Language features that change
stdout/stderr
will inevitably be fixed in newer test-suites to accomodate newer
compilers, but
will not work with older compilers.

However, we have a large body of public libraries on hackage.  And a curated
set of packages per compiler in the form Stackage LTS sets.  We have
something
slightly similar for HEAD with the hackage head overlay.  For older
compilers
we can rely on something more mature!

Thus, if we can build some automation to test a compiler against an
existing set
of packages, and run their test-suites. There will inevitably be failures,
but we'd
be interested in looking at the drivitive only anyway. If the same set of
tests fail
that previous compilers failed at, I don't think that should be much of
concern. If
fewer tests fail, it would indicate something might have been fixed, or the
test
now surfaces some new behaviour that we might want to look at.  Worst case
would be new test that fail, but didn't before.  This should raise red
flags and
either have a *very* good argument for why the backport is still the right
thing to
do and the test-failures are actually faulty tests, or the backport should
just not
be performed.

In the end it will be about striking a balance between fixing bugs and not
regressing, with a higher priority on not regressing.  However we if we
can't
detect we regress, we have to assume we don't, as we'd otherwise be unable
to even make any releases.

I'd be happy to discuss this further, and setup some nix based test harness
for
this, as time permits (with windows test being run through some cross
compilation
and wine based) setup.

Cheers,
 Moritz

On Sat, Aug 15, 2020 at 3:31 PM Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Hi there!
>
> Thanks everyone for showing interest. I've started a wiki page here:
> https://gitlab.haskell.org/ghc/ghc/-/wikis/ghc-maintainers
> Please add yourself to the release you'd like to maintain. I've tried
> to come up with a plan on how to actually look at this problem,
> and it appears to me that we want a list of Merge Requests that are
> considered for backporting, and then see to which GHC we
> backport them.  So essentially a matrix with GHC releases / merge
> requests, and values being either empty or the commit in which
> the MR was backported.
>
> To get the existing matrix we might try to extract this from the git
> history? Does anyone have a good idea how to do this properly?
> The alternative would be to go through all existing MRs, and check for
> backports, which would be quite tedious, and an automated
> solution (at least to get the initial matrix would be good?).  In
> general I believe there to be value in a matrix of backports for easy
> lookup.
>
> Then we'll need a good way to flag new incoming MRs for backports, and
> have the release maintainers look at them, and their
> applicability/suitability for a given release.
>
> Finally, let's not kid ourselves here, this will require some time
> investment, taking ownership and coordination. I don't think we need
> to rush releases, but we should make sure that releases are of good
> quality.
>
> Cheers,
>  Moritz
>
> On Tue, Aug 11, 2020 at 11:29 PM Hemanth Kapila <saihemanth at gmail.com>
> wrote:
> >
> > Thanks for the note.
> >
> > I will be happy to pitch in.
> >
> > Thanks,
> > Hemanth
> >
> > On Tue, 11 Aug 2020, 07:40 Moritz Angermann, <moritz.angermann at gmail.com>
> wrote:
> >>
> >> Hi there!
> >>
> >> As it stands right now, Ben is the one who works tirelessly trying to
> >> cut releases. Not just for the most recent version, but also for
> >> previous versions. Most recently 8.10.2, but we have 9.0 coming up as
> >> well.
> >>
> >> I know that there are some people who deeply care for personal or
> >> professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of
> >> them have stacks of patches applied, or proprietary extensions. I'd
> >> argue that most of those applied patches are backports of bug fixes
> >> and rarely language features, as language features will break
> >> compatibility (due to ghc, base, and other library versions anyway).
> >>
> >> I would therefore like drum up a group of people who will take care
> >> (ideally 2+ per release) of backporting and making minor partch
> >> releases. This does not have to go on forever, but it would take much
> >> needed load off of Ben to focus on what ever happens in ghc HEAD.
> >>
> >> So what would this work actually look like? It would consist of
> >> - going through the list of MRs and tagging those which are relevant
> >> for backporting to a certain release.
> >> - backport MRs where the MR does not cleanly apply.
> >> - fixup any test-suite failures.
> >> - agree on a date to cut/make the release.
> >>
> >> This is not a permanent commitment. I hope we can attract more people
> >> to the ghc release managers.
> >>
> >> I'm looking forward to great many responses. And I'm sure Ben will be
> >> able to help mentor us through cutting the first releases. I'll
> >> volunteer to be part of the 8.6 branch maintainers for now.
> >>
> >> Cheers,
> >>  Moritz
> >>
> >> PS: There is a slightly related discussion about release cadence and
> >> versions and how other projects deal with this in this ticket:
> >> https://gitlab.haskell.org/ghc/ghc/-/issues/18222
> >> _______________________________________________
> >> 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/20200818/e1de03cc/attachment-0001.html>

From ben at smart-cactus.org  Tue Aug 18 16:07:06 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 18 Aug 2020 12:07:06 -0400
Subject: Breakage on master
Message-ID: <87imdg7xaw.fsf@smart-cactus.org>

Hi all,

It seems that a patch breaking master for DEBUG-enabled builds has snuck
into `master`. I'm currently working on fixing the issue but in the
meantime the issue can be worked around by reverting
accbc242e555822a2060091af7188ce6e9b0144e.

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/20200818/25b779b3/attachment.sig>

From simonpj at microsoft.com  Tue Aug 18 16:27:19 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 18 Aug 2020 16:27:19 +0000
Subject: Breakage on master
In-Reply-To: <87imdg7xaw.fsf@smart-cactus.org>
References: <87imdg7xaw.fsf@smart-cactus.org>
Message-ID: <VI1PR83MB0429DDCEA9AEA5323701D9FDAD5C0@VI1PR83MB0429.EURPRD83.prod.outlook.com>

|  meantime the issue can be worked around by reverting
|  accbc242e555822a2060091af7188ce6e9b0144e.

Alas, not so.

git revert accbc242e555822a2060091af7188ce6e9b0144e
warning: Failed to merge submodule utils/haddock (commits don't follow merge-base)
error: could not revert accbc242e5... DynFlags: disentangle Outputable
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ben Gamari
|  Sent: 18 August 2020 17:07
|  To: GHC developers <ghc-devs at haskell.org>
|  Subject: Breakage on master
|  
|  Hi all,
|  
|  It seems that a patch breaking master for DEBUG-enabled builds has
|  snuck
|  into `master`. I'm currently working on fixing the issue but in the
|  meantime the issue can be worked around by reverting
|  accbc242e555822a2060091af7188ce6e9b0144e.
|  
|  Cheers,
|  
|  - Ben

From ben at smart-cactus.org  Tue Aug 18 16:42:20 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 18 Aug 2020 12:42:20 -0400
Subject: Breakage on master
In-Reply-To: <VI1PR83MB0429DDCEA9AEA5323701D9FDAD5C0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <87imdg7xaw.fsf@smart-cactus.org>
 <VI1PR83MB0429DDCEA9AEA5323701D9FDAD5C0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <87ft8j9a8n.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> |  meantime the issue can be worked around by reverting
> |  accbc242e555822a2060091af7188ce6e9b0144e.
>
> Alas, not so.
>
> git revert accbc242e555822a2060091af7188ce6e9b0144e
> warning: Failed to merge submodule utils/haddock (commits don't follow merge-base)
> error: could not revert accbc242e5... DynFlags: disentangle Outputable
> hint: after resolving the conflicts, mark the corrected paths
> hint: with 'git add <paths>' or 'git rm <paths>'
> hint: and commit the result with 'git commit'
>
Sigh, yes, this is what I was afraid of. Strangely, Hadrian's validate
flavour doesn't appear to be affected by the issue that you reported.
Are you using the make build system by any chance?

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/20200818/4b47d4f7/attachment.sig>

From ben at smart-cactus.org  Tue Aug 18 19:04:06 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 18 Aug 2020 15:04:06 -0400
Subject: Breakage on master
In-Reply-To: <87ft8j9a8n.fsf@smart-cactus.org>
References: <87imdg7xaw.fsf@smart-cactus.org>
 <VI1PR83MB0429DDCEA9AEA5323701D9FDAD5C0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <87ft8j9a8n.fsf@smart-cactus.org>
Message-ID: <87d03n93od.fsf@smart-cactus.org>

Ben Gamari <ben at smart-cactus.org> writes:

> Simon Peyton Jones <simonpj at microsoft.com> writes:
>
>> |  meantime the issue can be worked around by reverting
>> |  accbc242e555822a2060091af7188ce6e9b0144e.
>>
>> Alas, not so.
>>
>> git revert accbc242e555822a2060091af7188ce6e9b0144e
>> warning: Failed to merge submodule utils/haddock (commits don't follow merge-base)
>> error: could not revert accbc242e5... DynFlags: disentangle Outputable
>> hint: after resolving the conflicts, mark the corrected paths
>> hint: with 'git add <paths>' or 'git rm <paths>'
>> hint: and commit the result with 'git commit'
>>
> Sigh, yes, this is what I was afraid of. Strangely, Hadrian's validate
> flavour doesn't appear to be affected by the issue that you reported.
> Are you using the make build system by any chance?
>
Strangely, `./validate --legacy --slow` also appears to work fine for me
on 55fd1dc55990623dcf3b2e6143e766242315d757.

Simon, can you describe how you were previously building GHC?

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/20200818/73e0cd9d/attachment.sig>

From simonpj at microsoft.com  Wed Aug 19 08:24:09 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 19 Aug 2020 08:24:09 +0000
Subject: Breakage on master
In-Reply-To: <87d03n93od.fsf@smart-cactus.org>
References: <87imdg7xaw.fsf@smart-cactus.org>
 <VI1PR83MB0429DDCEA9AEA5323701D9FDAD5C0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <87ft8j9a8n.fsf@smart-cactus.org> <87d03n93od.fsf@smart-cactus.org>
Message-ID: <VI1PR83MB0429DF9550B8A66482F27F4AAD5D0@VI1PR83MB0429.EURPRD83.prod.outlook.com>

|  Strangely, `./validate --legacy --slow` also appears to work fine for
|  me
|  on 55fd1dc55990623dcf3b2e6143e766242315d757.
|  
|  Simon, can you describe how you were previously building GHC?

./validate --legacy --fast

with this validate.mk (below).

But the issue is terribly simple: assertPprPanic is used (by ASSERT), but no longer imported (by many many modules) because they previously got it from Outputable.  How can this possibly work?  It certainly doesn't for me.

Would it be possible to revert the patch that broke this?  I'm fully stalled with no workaround.

Thanks

Simon



SRC_HC_OPTS        = -O -H64m
GhcStage1HcOpts    = -DDEBUG
GhcStage2HcOpts    = -dcore-lint -ticky
GhcLibHcOpts       = -O -dcore-lint -ticky

BUILD_PROF_LIBS    = NO
SplitSections      = NO
HADDOCK_DOCS       = NO
BUILD_SPHINX_HTML  = NO
BUILD_SPHINX_PDF   = NO
BUILD_MAN          = NO

LAX_DEPENDENCIES   = YES


|  -----Original Message-----
|  From: Ben Gamari <ben at smart-cactus.org>
|  Sent: 18 August 2020 20:04
|  To: Simon Peyton Jones <simonpj at microsoft.com>; GHC developers <ghc-
|  devs at haskell.org>
|  Subject: RE: Breakage on master
|  
|  Ben Gamari <ben at smart-cactus.org> writes:
|  
|  > Simon Peyton Jones <simonpj at microsoft.com> writes:
|  >
|  >> |  meantime the issue can be worked around by reverting
|  >> |  accbc242e555822a2060091af7188ce6e9b0144e.
|  >>
|  >> Alas, not so.
|  >>
|  >> git revert accbc242e555822a2060091af7188ce6e9b0144e
|  >> warning: Failed to merge submodule utils/haddock (commits don't
|  follow merge-base)
|  >> error: could not revert accbc242e5... DynFlags: disentangle
|  Outputable
|  >> hint: after resolving the conflicts, mark the corrected paths
|  >> hint: with 'git add <paths>' or 'git rm <paths>'
|  >> hint: and commit the result with 'git commit'
|  >>
|  > Sigh, yes, this is what I was afraid of. Strangely, Hadrian's
|  validate
|  > flavour doesn't appear to be affected by the issue that you
|  reported.
|  > Are you using the make build system by any chance?
|  >
|  Strangely, `./validate --legacy --slow` also appears to work fine for
|  me
|  on 55fd1dc55990623dcf3b2e6143e766242315d757.
|  
|  Simon, can you describe how you were previously building GHC?
|  
|  Cheers,
|  
|  - Ben

From sylvain at haskus.fr  Wed Aug 19 10:53:27 2020
From: sylvain at haskus.fr (Sylvain Henry)
Date: Wed, 19 Aug 2020 12:53:27 +0200
Subject: Breakage on master
In-Reply-To: <VI1PR83MB0429DF9550B8A66482F27F4AAD5D0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <87imdg7xaw.fsf@smart-cactus.org>
 <VI1PR83MB0429DDCEA9AEA5323701D9FDAD5C0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <87ft8j9a8n.fsf@smart-cactus.org> <87d03n93od.fsf@smart-cactus.org>
 <VI1PR83MB0429DF9550B8A66482F27F4AAD5D0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <447d22f8-4c3a-4824-6a61-168eaa0db7fe@haskus.fr>

I can't reproduce the issue. Is it on a specific branch?

If it's in a branch with new ASSERTs, you should just have to import 
GHC.Utils.Panic to fix the issue or is there something else?

Sylvain

On 19/08/2020 10:24, Simon Peyton Jones via ghc-devs wrote:
> |  Strangely, `./validate --legacy --slow` also appears to work fine for
> |  me
> |  on 55fd1dc55990623dcf3b2e6143e766242315d757.
> |
> |  Simon, can you describe how you were previously building GHC?
>
> ./validate --legacy --fast
>
> with this validate.mk (below).
>
> But the issue is terribly simple: assertPprPanic is used (by ASSERT), but no longer imported (by many many modules) because they previously got it from Outputable.  How can this possibly work?  It certainly doesn't for me.
>
> Would it be possible to revert the patch that broke this?  I'm fully stalled with no workaround.
>
> Thanks
>
> Simon
>
>
>
> SRC_HC_OPTS        = -O -H64m
> GhcStage1HcOpts    = -DDEBUG
> GhcStage2HcOpts    = -dcore-lint -ticky
> GhcLibHcOpts       = -O -dcore-lint -ticky
>
> BUILD_PROF_LIBS    = NO
> SplitSections      = NO
> HADDOCK_DOCS       = NO
> BUILD_SPHINX_HTML  = NO
> BUILD_SPHINX_PDF   = NO
> BUILD_MAN          = NO
>
> LAX_DEPENDENCIES   = YES
>
>
> |  -----Original Message-----
> |  From: Ben Gamari <ben at smart-cactus.org>
> |  Sent: 18 August 2020 20:04
> |  To: Simon Peyton Jones <simonpj at microsoft.com>; GHC developers <ghc-
> |  devs at haskell.org>
> |  Subject: RE: Breakage on master
> |
> |  Ben Gamari <ben at smart-cactus.org> writes:
> |
> |  > Simon Peyton Jones <simonpj at microsoft.com> writes:
> |  >
> |  >> |  meantime the issue can be worked around by reverting
> |  >> |  accbc242e555822a2060091af7188ce6e9b0144e.
> |  >>
> |  >> Alas, not so.
> |  >>
> |  >> git revert accbc242e555822a2060091af7188ce6e9b0144e
> |  >> warning: Failed to merge submodule utils/haddock (commits don't
> |  follow merge-base)
> |  >> error: could not revert accbc242e5... DynFlags: disentangle
> |  Outputable
> |  >> hint: after resolving the conflicts, mark the corrected paths
> |  >> hint: with 'git add <paths>' or 'git rm <paths>'
> |  >> hint: and commit the result with 'git commit'
> |  >>
> |  > Sigh, yes, this is what I was afraid of. Strangely, Hadrian's
> |  validate
> |  > flavour doesn't appear to be affected by the issue that you
> |  reported.
> |  > Are you using the make build system by any chance?
> |  >
> |  Strangely, `./validate --legacy --slow` also appears to work fine for
> |  me
> |  on 55fd1dc55990623dcf3b2e6143e766242315d757.
> |
> |  Simon, can you describe how you were previously building GHC?
> |
> |  Cheers,
> |
> |  - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Wed Aug 19 11:12:49 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 19 Aug 2020 11:12:49 +0000
Subject: Breakage on master
In-Reply-To: <447d22f8-4c3a-4824-6a61-168eaa0db7fe@haskus.fr>
References: <87imdg7xaw.fsf@smart-cactus.org>
 <VI1PR83MB0429DDCEA9AEA5323701D9FDAD5C0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <87ft8j9a8n.fsf@smart-cactus.org> <87d03n93od.fsf@smart-cactus.org>
 <VI1PR83MB0429DF9550B8A66482F27F4AAD5D0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <447d22f8-4c3a-4824-6a61-168eaa0db7fe@haskus.fr>
Message-ID: <VI1PR83MB04294E7695E3D92BE66ECB3DAD5D0@VI1PR83MB0429.EURPRD83.prod.outlook.com>

|  > But the issue is terribly simple: assertPprPanic is used (by
|  ASSERT), but no longer imported (by many many modules) because they
|  previously got it from Outputable.  How can this possibly work?  

I believe that that the answer to my qn is "just import GHC.Utils.Panic".

More specifically, as part of your patch, in future, if you want to use ASSERTs you must

* BOTH #include HsVersions.h
* AND  import GHC.Utils.Panic

and that you have added that extra import to the zillion existing modules that have an ASSERT.

I had not understood that change.  I think all I need do is to add the extra import to my new modules in !3220.

It would be helpful to add a prominent comment in HsVersions.h.

I still wonder whether HsVersions.h could simply include 'import GHC.Utils.Panic' to save this clutter.  But regardless, I think I'm unstuck now.  Thanks

Simon



|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Sylvain
|  Henry
|  Sent: 19 August 2020 11:53
|  To: ghc-devs at haskell.org
|  Subject: Re: Breakage on master
|  
|  I can't reproduce the issue. Is it on a specific branch?
|  
|  If it's in a branch with new ASSERTs, you should just have to import
|  GHC.Utils.Panic to fix the issue or is there something else?
|  
|  Sylvain
|  
|  On 19/08/2020 10:24, Simon Peyton Jones via ghc-devs wrote:
|  > |  Strangely, `./validate --legacy --slow` also appears to work fine
|  for
|  > |  me
|  > |  on 55fd1dc55990623dcf3b2e6143e766242315d757.
|  > |
|  > |  Simon, can you describe how you were previously building GHC?
|  >
|  > ./validate --legacy --fast
|  >
|  > with this validate.mk (below).
|  >
|  > But the issue is terribly simple: assertPprPanic is used (by
|  ASSERT), but no longer imported (by many many modules) because they
|  previously got it from Outputable.  How can this possibly work?  It
|  certainly doesn't for me.
|  >
|  > Would it be possible to revert the patch that broke this?  I'm fully
|  stalled with no workaround.
|  >
|  > Thanks
|  >
|  > Simon
|  >
|  >
|  >
|  > SRC_HC_OPTS        = -O -H64m
|  > GhcStage1HcOpts    = -DDEBUG
|  > GhcStage2HcOpts    = -dcore-lint -ticky
|  > GhcLibHcOpts       = -O -dcore-lint -ticky
|  >
|  > BUILD_PROF_LIBS    = NO
|  > SplitSections      = NO
|  > HADDOCK_DOCS       = NO
|  > BUILD_SPHINX_HTML  = NO
|  > BUILD_SPHINX_PDF   = NO
|  > BUILD_MAN          = NO
|  >
|  > LAX_DEPENDENCIES   = YES
|  >
|  >
|  > |  -----Original Message-----
|  > |  From: Ben Gamari <ben at smart-cactus.org>
|  > |  Sent: 18 August 2020 20:04
|  > |  To: Simon Peyton Jones <simonpj at microsoft.com>; GHC developers
|  <ghc-
|  > |  devs at haskell.org>
|  > |  Subject: RE: Breakage on master
|  > |
|  > |  Ben Gamari <ben at smart-cactus.org> writes:
|  > |
|  > |  > Simon Peyton Jones <simonpj at microsoft.com> writes:
|  > |  >
|  > |  >> |  meantime the issue can be worked around by reverting
|  > |  >> |  accbc242e555822a2060091af7188ce6e9b0144e.
|  > |  >>
|  > |  >> Alas, not so.
|  > |  >>
|  > |  >> git revert accbc242e555822a2060091af7188ce6e9b0144e
|  > |  >> warning: Failed to merge submodule utils/haddock (commits
|  don't
|  > |  follow merge-base)
|  > |  >> error: could not revert accbc242e5... DynFlags: disentangle
|  > |  Outputable
|  > |  >> hint: after resolving the conflicts, mark the corrected paths
|  > |  >> hint: with 'git add <paths>' or 'git rm <paths>'
|  > |  >> hint: and commit the result with 'git commit'
|  > |  >>
|  > |  > Sigh, yes, this is what I was afraid of. Strangely, Hadrian's
|  > |  validate
|  > |  > flavour doesn't appear to be affected by the issue that you
|  > |  reported.
|  > |  > Are you using the make build system by any chance?
|  > |  >
|  > |  Strangely, `./validate --legacy --slow` also appears to work fine
|  for
|  > |  me
|  > |  on 55fd1dc55990623dcf3b2e6143e766242315d757.
|  > |
|  > |  Simon, can you describe how you were previously building GHC?
|  > |
|  > |  Cheers,
|  > |
|  > |  - Ben
|  > _______________________________________________
|  > 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=02%7C01%7Csimonpj%40microsoft.com%7Cee9f099b376042e0fb6c
|  08d8442e2b39%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637334312373
|  953419&amp;sdata=6XaNrQIfRNqlSnXPAmoxXYTYQorYszHmyJc1kThIU2o%3D&amp;re
|  served=0
|  _______________________________________________
|  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=02%7C01%7Csimonpj%40microsoft.com%7Cee9f099b376042e0fb6c
|  08d8442e2b39%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637334312373
|  963414&amp;sdata=m2rdARx2tpZFv5I2WiEdYE5d37LeXTMIIPg51Zfee9M%3D&amp;re
|  served=0

From ben at well-typed.com  Mon Aug 24 18:01:17 2020
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 24 Aug 2020 14:01:17 -0400
Subject: Haskell Implementors' Workshop lightning talks
Message-ID: <87h7srly8p.fsf@smart-cactus.org>

Hello everyone,

The Haskell Implementors' Workshop will be held this Friday, August
28th, colocated with virtual ICFP. As usual, we will have a number of
slots for lightning-talks. These are five-minute-long talks where you
can present libraries, language extension ideas, plugins, tools...
anything that the Haskell implementor community might find interesting.

We are collecting talk submissions via Google Forms [1] and will notify
speakers of their slots on August 27th. We are looking forward to seeing
you there!

Cheers,

- Ben


[1] https://forms.gle/a8sZQNRRMe9H9YnX8 
-------------- 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/20200824/e93d77ac/attachment.sig>

From simonpj at microsoft.com  Tue Aug 25 22:26:05 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 25 Aug 2020 22:26:05 +0000
Subject: Perf baselines
Message-ID: <VI1PR83MB04298B29D2719F2A324E8F6DAD570@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Ben
CI is saying (on !3889)
Missing Baseline Metrics these metrics trivially pass because a baseline (expected value) cannot be recovered from previous git commits. This may be due to HEAD having new tests or having expected changes, the presence of expected changes since the last run of the tests, and/or the latest test run being too old.
T18223 T12425 T13253
Now it's true that T18223 is new, but T12425 and T13253 are not.
What's wrong?
Thanks
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200825/8a8ab529/attachment.html>

From arnaud.spiwack at tweag.io  Fri Aug 28 13:04:12 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 28 Aug 2020 15:04:12 +0200
Subject: Implicit reboxing of unboxed tuple in let-patterns
Message-ID: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>

Dear all,

I discovered the hard way, yesterday, that lazy let pattern
matching is allowed on unboxed tuples. And that it implicitly reboxes
the pattern.

Here is how the manual describes it, from the relevant section
<https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-UnboxedTuples>
:

You can have an unboxed tuple in a pattern binding, thus

f x = let (# p,q #) = h x in ..body..

If the types of p and q are not unboxed, the resulting binding is lazy like
any other Haskell pattern binding. The above example desugars like this:

f x = let t = case h x of { (# p,q #) -> (p,q) }
          p = fst t
          q = snd t
      in ..body..

Indeed, the bindings can even be recursive.

Notice how h x is lazily bound, hence won’t necessarily be run when
body is forced. as opposed to if I had written, for instance,

let u = hxin ..body..

My question is: are we happy with this? I did find this extremely
surprising. If I’m using unboxed tuples, it’s because I want to
guarantee to myself a strict, unboxed behaviour. But a very subtle
syntactic detail seems to break this expectation for me. My
expectation would be that I would need to explicitly rebox things
before they get lazy again.

I find that this behaviour invites trouble. But you may disagree. Let
me know!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200828/18ed781e/attachment.html>

From carter.schonwald at gmail.com  Fri Aug 28 13:20:04 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 28 Aug 2020 09:20:04 -0400
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
Message-ID: <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>

Have you tried using do notation for bindings you want to keep strict, with
Eg the identity monad?  That doesn’t address  the design critique but gives
you a path forward ?

I do agree that the semantics / default recursivity Of let bindings  can be
inappropriate for non recursive code , but would any other non uniform
semantics or optimization be safe?

On Fri, Aug 28, 2020 at 9:05 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
>
> I discovered the hard way, yesterday, that lazy let pattern
> matching is allowed on unboxed tuples. And that it implicitly reboxes
> the pattern.
>
>
> Here is how the manual describes it, from the relevant section
> <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-UnboxedTuples>
> :
>
>
>
>
> You can have an unboxed tuple in a pattern binding, thus
>
>
> f x = let (# p,q #) = h x in ..body..
>
>
>
> If the types of p and q are not unboxed, the resulting binding is lazy
> like any other Haskell pattern binding. The above example desugars like
> this:
>
>
> f x = let t = case h x of { (# p,q #) -> (p,q) }
>
>           p = fst t
>
>           q = snd t
>
>       in ..body..
>
>
>
> Indeed, the bindings can even be recursive.
>
>
>
>
> Notice how h x is lazily bound, hence won’t necessarily be run when
> body is forced. as opposed to if I had written, for instance,
>
>
> let u = hx
>
> in ..body..
>
>
>
> My question is: are we happy with this? I did find this extremely
> surprising. If I’m using unboxed tuples, it’s because I want to
> guarantee to myself a strict, unboxed behaviour. But a very subtle
> syntactic detail seems to break this expectation for me. My
> expectation would be that I would need to explicitly rebox things
> before they get lazy again.
>
>
> I find that this behaviour invites trouble. But you may disagree. Let
> me know!
>
>
>
>
> _______________________________________________
>
> 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/20200828/f527cc0b/attachment.html>

From arnaud.spiwack at tweag.io  Fri Aug 28 13:25:32 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 28 Aug 2020 15:25:32 +0200
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
Message-ID: <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>

Hi Carter,

We are using let !(#x,y#) = … actually. Having the strict behaviour is not
particularly difficult. You can even use case … of (#x, y#) ->… directly,
it’s not too bad. My complaint, as it were, is solely about the potential
for mistakes.

On Fri, Aug 28, 2020 at 3:20 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Have you tried using do notation for bindings you want to keep strict,
> with Eg the identity monad?  That doesn’t address  the design critique but
> gives you a path forward ?
>
> I do agree that the semantics / default recursivity Of let bindings  can
> be inappropriate for non recursive code , but would any other non uniform
> semantics or optimization be safe?
>
> On Fri, Aug 28, 2020 at 9:05 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all,
>>
>>
>> I discovered the hard way, yesterday, that lazy let pattern
>> matching is allowed on unboxed tuples. And that it implicitly reboxes
>> the pattern.
>>
>>
>> Here is how the manual describes it, from the relevant section
>> <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-UnboxedTuples>
>> :
>>
>>
>>
>>
>> You can have an unboxed tuple in a pattern binding, thus
>>
>>
>> f x = let (# p,q #) = h x in ..body..
>>
>>
>>
>> If the types of p and q are not unboxed, the resulting binding is lazy
>> like any other Haskell pattern binding. The above example desugars like
>> this:
>>
>>
>> f x = let t = case h x of { (# p,q #) -> (p,q) }
>>
>>           p = fst t
>>
>>           q = snd t
>>
>>       in ..body..
>>
>>
>>
>> Indeed, the bindings can even be recursive.
>>
>>
>>
>>
>> Notice how h x is lazily bound, hence won’t necessarily be run when
>> body is forced. as opposed to if I had written, for instance,
>>
>>
>> let u = hx
>>
>> in ..body..
>>
>>
>>
>> My question is: are we happy with this? I did find this extremely
>> surprising. If I’m using unboxed tuples, it’s because I want to
>> guarantee to myself a strict, unboxed behaviour. But a very subtle
>> syntactic detail seems to break this expectation for me. My
>> expectation would be that I would need to explicitly rebox things
>> before they get lazy again.
>>
>>
>> I find that this behaviour invites trouble. But you may disagree. Let
>> me know!
>>
>>
>>
>>
>> _______________________________________________
>>
>> 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/20200828/69bb2a92/attachment.html>

From chessai1996 at gmail.com  Fri Aug 28 18:25:57 2020
From: chessai1996 at gmail.com (chessai)
Date: Fri, 28 Aug 2020 13:25:57 -0500
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
Message-ID: <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>

Arnaud,

I have dealt with this in the past and find the laziness extremely
counterintuitive and never wanted. Every time I have let-bound an unboxed
tuple, I have never wanted that boxing to occur. Perhaps there is a good
reason this is the case but I wish it would change.

On Fri, Aug 28, 2020, 08:26 Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:

> Hi Carter,
>
> We are using let !(#x,y#) = … actually. Having the strict behaviour is
> not particularly difficult. You can even use case … of (#x, y#) ->…
> directly, it’s not too bad. My complaint, as it were, is solely about the
> potential for mistakes.
>
> On Fri, Aug 28, 2020 at 3:20 PM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> Have you tried using do notation for bindings you want to keep strict,
>> with Eg the identity monad?  That doesn’t address  the design critique but
>> gives you a path forward ?
>>
>> I do agree that the semantics / default recursivity Of let bindings  can
>> be inappropriate for non recursive code , but would any other non uniform
>> semantics or optimization be safe?
>>
>> On Fri, Aug 28, 2020 at 9:05 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> Dear all,
>>>
>>>
>>> I discovered the hard way, yesterday, that lazy let pattern
>>> matching is allowed on unboxed tuples. And that it implicitly reboxes
>>> the pattern.
>>>
>>>
>>> Here is how the manual describes it, from the relevant section
>>> <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-UnboxedTuples>
>>> :
>>>
>>>
>>>
>>>
>>> You can have an unboxed tuple in a pattern binding, thus
>>>
>>>
>>> f x = let (# p,q #) = h x in ..body..
>>>
>>>
>>>
>>> If the types of p and q are not unboxed, the resulting binding is lazy
>>> like any other Haskell pattern binding. The above example desugars like
>>> this:
>>>
>>>
>>> f x = let t = case h x of { (# p,q #) -> (p,q) }
>>>
>>>           p = fst t
>>>
>>>           q = snd t
>>>
>>>       in ..body..
>>>
>>>
>>>
>>> Indeed, the bindings can even be recursive.
>>>
>>>
>>>
>>>
>>> Notice how h x is lazily bound, hence won’t necessarily be run when
>>> body is forced. as opposed to if I had written, for instance,
>>>
>>>
>>> let u = hx
>>>
>>> in ..body..
>>>
>>>
>>>
>>> My question is: are we happy with this? I did find this extremely
>>> surprising. If I’m using unboxed tuples, it’s because I want to
>>> guarantee to myself a strict, unboxed behaviour. But a very subtle
>>> syntactic detail seems to break this expectation for me. My
>>> expectation would be that I would need to explicitly rebox things
>>> before they get lazy again.
>>>
>>>
>>> I find that this behaviour invites trouble. But you may disagree. Let
>>> me know!
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> 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/20200828/68318b43/attachment.html>

From kiss.csongor.kiss at gmail.com  Fri Aug 28 22:32:32 2020
From: kiss.csongor.kiss at gmail.com (Csongor Kiss)
Date: Fri, 28 Aug 2020 23:32:32 +0100
Subject: Parsing funny arrows
Message-ID: <921588CB-1578-46A8-8ED7-0100DEDD7883@gmail.com>

Hello devs,

I am trying to modify GHC's parser to allow the following syntax in types:

  a -> @m b

but my naive attempt was unsuccessful:

type :: { LHsType GhcPs }
        : btype                        { $1 }
        | btype '->' PREFIX_AT btype ctype  ...

For example when I try to parse the following code (and turn on the lexer debug log):
  
  test :: a -> @m b
  test = undefined

I get the following 

token: ITvarid "test"
token: ITdcolon NormalSyntax
token: ITvarid "a"
token: ITrarrow NormalSyntax
token: ITtypeApp
token: ITvarid "m"
token: ITvarid "b"
token: ITsemi

Parse.hs:2:1: error:
    parse error (possibly incorrect indentation or mismatched brackets)
  |
2 | test = undefined


I don't have much experience with hacking on the parser so I'm likely missing something obvious.
Could someone please point at what I might be doing wrong?

Thanks in advance.

Cheers,
Csongor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200828/88e138ac/attachment.html>

From vladislav at serokell.io  Fri Aug 28 23:38:23 2020
From: vladislav at serokell.io (Vladislav Zavialov)
Date: Sat, 29 Aug 2020 02:38:23 +0300
Subject: Parsing funny arrows
In-Reply-To: <921588CB-1578-46A8-8ED7-0100DEDD7883@gmail.com>
References: <921588CB-1578-46A8-8ED7-0100DEDD7883@gmail.com>
Message-ID: <BF779FF6-7F54-4DF0-AB67-8BC0E31D48B6@serokell.io>

Hi Csongor,

I believe the reason for this failure is that  a -> @m b  gets parsed as  a -> @(m b).
Why is that? Because a ‘btype’ includes type-level application.

If you replace the ‘btype’ after PREFIX_AT with an ‘atype’, this particular issue should go away. At least that’s my hypothesis, I haven’t tested it.

- Vlad

> On 29 Aug 2020, at 01:32, Csongor Kiss <kiss.csongor.kiss at gmail.com> wrote:
> 
> Hello devs,
> 
> I am trying to modify GHC's parser to allow the following syntax in types:
> 
>   a -> @m b
> 
> but my naive attempt was unsuccessful:
> 
> type :: { LHsType GhcPs }
>         : btype                        { $1 }
>         | btype '->' PREFIX_AT btype ctype  ...
> 
> For example when I try to parse the following code (and turn on the lexer debug log):
>   
>   test :: a -> @m b
>   test = undefined
> 
> I get the following 
> 
> token: ITvarid "test"
> token: ITdcolon NormalSyntax
> token: ITvarid "a"
> token: ITrarrow NormalSyntax
> token: ITtypeApp
> token: ITvarid "m"
> token: ITvarid "b"
> token: ITsemi
> 
> Parse.hs:2:1: error:
>     parse error (possibly incorrect indentation or mismatched brackets)
>   |
> 2 | test = undefined
> 
> 
> I don't have much experience with hacking on the parser so I'm likely missing something obvious.
> Could someone please point at what I might be doing wrong?
> 
> Thanks in advance.
> 
> Cheers,
> Csongor
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From shayne.fletcher.50 at gmail.com  Fri Aug 28 23:48:32 2020
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Fri, 28 Aug 2020 19:48:32 -0400
Subject: Parsing funny arrows
In-Reply-To: <BF779FF6-7F54-4DF0-AB67-8BC0E31D48B6@serokell.io>
References: <921588CB-1578-46A8-8ED7-0100DEDD7883@gmail.com>
 <BF779FF6-7F54-4DF0-AB67-8BC0E31D48B6@serokell.io>
Message-ID: <CAMsAzy9OEAKYm1oLZXUzNiw+wAnwLb==A=_VQXYSaYBuyOKCPA@mail.gmail.com>

On Fri, Aug 28, 2020 at 7:38 PM Vladislav Zavialov <vladislav at serokell.io>
wrote:

> Hi Csongor,
>
> I believe the reason for this failure is that  a -> @m b  gets parsed as
> a -> @(m b).
> Why is that? Because a ‘btype’ includes type-level application.
>
> If you replace the ‘btype’ after PREFIX_AT with an ‘atype’, this
> particular issue should go away. At least that’s my hypothesis, I haven’t
> tested it.
>
>
I confirm that this is correct and with that change the example string
reduces as hoped.


- Vlad
>

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

From shayne.fletcher.50 at gmail.com  Fri Aug 28 23:51:45 2020
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Fri, 28 Aug 2020 19:51:45 -0400
Subject: Parsing funny arrows
In-Reply-To: <CAMsAzy9OEAKYm1oLZXUzNiw+wAnwLb==A=_VQXYSaYBuyOKCPA@mail.gmail.com>
References: <921588CB-1578-46A8-8ED7-0100DEDD7883@gmail.com>
 <BF779FF6-7F54-4DF0-AB67-8BC0E31D48B6@serokell.io>
 <CAMsAzy9OEAKYm1oLZXUzNiw+wAnwLb==A=_VQXYSaYBuyOKCPA@mail.gmail.com>
Message-ID: <CAMsAzy9+5vjzM=7qRRaecd0MAqm3LANudiW+VTyfXu7A0_VnCQ@mail.gmail.com>

On Fri, Aug 28, 2020 at 7:48 PM Shayne Fletcher <
shayne.fletcher.50 at gmail.com> wrote:

>
>
> On Fri, Aug 28, 2020 at 7:38 PM Vladislav Zavialov <vladislav at serokell.io>
> wrote:
>
>> Hi Csongor,
>>
>> I believe the reason for this failure is that  a -> @m b  gets parsed as
>> a -> @(m b).
>> Why is that? Because a ‘btype’ includes type-level application.
>>
>> If you replace the ‘btype’ after PREFIX_AT with an ‘atype’, this
>> particular issue should go away. At least that’s my hypothesis, I haven’t
>> tested it.
>>
>>
> I confirm that this is correct and with that change the example string
> reduces as hoped.
>
>
> - Vlad
>>
>
Also, with that correction there are no new shift/reduce conflicts. The
original rule gave rise to 3.

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

From kiss.csongor.kiss at gmail.com  Sat Aug 29 07:16:46 2020
From: kiss.csongor.kiss at gmail.com (Csongor Kiss)
Date: Sat, 29 Aug 2020 08:16:46 +0100
Subject: Parsing funny arrows
In-Reply-To: <CAMsAzy9+5vjzM=7qRRaecd0MAqm3LANudiW+VTyfXu7A0_VnCQ@mail.gmail.com>
References: <921588CB-1578-46A8-8ED7-0100DEDD7883@gmail.com>
 <BF779FF6-7F54-4DF0-AB67-8BC0E31D48B6@serokell.io>
 <CAMsAzy9OEAKYm1oLZXUzNiw+wAnwLb==A=_VQXYSaYBuyOKCPA@mail.gmail.com>
 <CAMsAzy9+5vjzM=7qRRaecd0MAqm3LANudiW+VTyfXu7A0_VnCQ@mail.gmail.com>
Message-ID: <AF59BBEF-B81A-4FF9-846F-8606AD63C449@gmail.com>

Thanks a lot Vlad and Shayne, that indeed did the trick!

Out of curiosity, how could I have figured out that this was the culprit? The parse
error I got was a bit puzzling, and I couldn't find any flags that would give more information
(I think I was looking for the parser equivalent of -ddump-tc-trace).

Best,
Csongor

> On 29 Aug 2020, at 00:51, Shayne Fletcher <shayne.fletcher.50 at gmail.com> wrote:
> 
> 
> 
> On Fri, Aug 28, 2020 at 7:48 PM Shayne Fletcher <shayne.fletcher.50 at gmail.com <mailto:shayne.fletcher.50 at gmail.com>> wrote:
> 
> 
> On Fri, Aug 28, 2020 at 7:38 PM Vladislav Zavialov <vladislav at serokell.io <mailto:vladislav at serokell.io>> wrote:
> Hi Csongor,
> 
> I believe the reason for this failure is that  a -> @m b  gets parsed as  a -> @(m b).
> Why is that? Because a ‘btype’ includes type-level application.
> 
> If you replace the ‘btype’ after PREFIX_AT with an ‘atype’, this particular issue should go away. At least that’s my hypothesis, I haven’t tested it.
> 
> 
> I confirm that this is correct and with that change the example string reduces as hoped.
> 
> 
> - Vlad
> 
> Also, with that correction there are no new shift/reduce conflicts. The original rule gave rise to 3.
> 
> -- 
> Shayne Fletcher

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

From vladislav at serokell.io  Sat Aug 29 08:05:38 2020
From: vladislav at serokell.io (Vladislav Zavialov)
Date: Sat, 29 Aug 2020 11:05:38 +0300
Subject: Parsing funny arrows
In-Reply-To: <AF59BBEF-B81A-4FF9-846F-8606AD63C449@gmail.com>
References: <921588CB-1578-46A8-8ED7-0100DEDD7883@gmail.com>
 <BF779FF6-7F54-4DF0-AB67-8BC0E31D48B6@serokell.io>
 <CAMsAzy9OEAKYm1oLZXUzNiw+wAnwLb==A=_VQXYSaYBuyOKCPA@mail.gmail.com>
 <CAMsAzy9+5vjzM=7qRRaecd0MAqm3LANudiW+VTyfXu7A0_VnCQ@mail.gmail.com>
 <AF59BBEF-B81A-4FF9-846F-8606AD63C449@gmail.com>
Message-ID: <7915D7A7-6CB7-43E8-90A4-6935E1569E32@serokell.io>

The lexer produces only as many tokens as the parser requires. In the ‘lexerDbg’ dump that you included in the message, there were these lines:

  token: ITvarid "m"
  token: ITvarid "b"
  token: ITsemi

So I knew that the parser consumed the entire string, up to the virtual semicolon. I also recognized the parse error as the one produced by ‘happy’ rather than by a later validation pass. So even though the parser consumed the entire string, it failed. Therefore, it didn’t expect this string to end so abruptly, it expected it to continue.

But what did it expect to find? To figure it out, we need to know which grammar production is involved in the failure. The only grammar production that could’ve consumed the ‘->’ PREFIX_AT sequence successfully and proceed to process the rest of the string is this one:

   btype '->' PREFIX_AT btype ctype

By inspecting the definitions of ‘btype’ and ‘ctype’, one can see that neither of those accept the empty string, and both of those accept type-level function application. Thus it’s possible that ‘btype’ consumed “m b” as an application, and ‘ctype’ failed because it didn’t accept the remaining empty string:

  btype = “m b”
  ctype = parse error (nothing to consume)

But what you wanted instead was:

  btype = “m”
  ctype = “b”

The solution is to use ‘atype’ instead of ‘btype’, as ‘atype’ does not accept type-level application.

By the way, there’s also the input string on which the original grammar would’ve succeeded (or at least I think so):

  test :: a -> @m forall b. b
  test = undefined

That’s because ‘btype’ wouldn’t have consumed the ‘forall’, it would’ve stopped at this point. And then ‘ctype’ could’ve consumed “forall b. b”.

I don’t think there’s a parser equivalent of -ddump-tc-trace. You’ll need to figure this stuff out by reading the grammar and keeping in mind that ‘happy’ generates a shift-reduce parser that does not backtrack. The ‘lexerDbg’ output is useful to see how far the parser got. And there’s also this command in case you want to go low level and inspect the state machine generated by ‘happy’:

    happy -agc --strict compiler/GHC/Parser.y -idetailed-info

Hope this helps,
- Vlad

> On 29 Aug 2020, at 10:16, Csongor Kiss <kiss.csongor.kiss at gmail.com> wrote:
> 
> Thanks a lot Vlad and Shayne, that indeed did the trick!
> 
> Out of curiosity, how could I have figured out that this was the culprit? The parse
> error I got was a bit puzzling, and I couldn't find any flags that would give more information
> (I think I was looking for the parser equivalent of -ddump-tc-trace).
> 
> Best,
> Csongor


From kiss.csongor.kiss at gmail.com  Sat Aug 29 08:13:18 2020
From: kiss.csongor.kiss at gmail.com (Csongor Kiss)
Date: Sat, 29 Aug 2020 09:13:18 +0100
Subject: Parsing funny arrows
In-Reply-To: <7915D7A7-6CB7-43E8-90A4-6935E1569E32@serokell.io>
References: <921588CB-1578-46A8-8ED7-0100DEDD7883@gmail.com>
 <BF779FF6-7F54-4DF0-AB67-8BC0E31D48B6@serokell.io>
 <CAMsAzy9OEAKYm1oLZXUzNiw+wAnwLb==A=_VQXYSaYBuyOKCPA@mail.gmail.com>
 <CAMsAzy9+5vjzM=7qRRaecd0MAqm3LANudiW+VTyfXu7A0_VnCQ@mail.gmail.com>
 <AF59BBEF-B81A-4FF9-846F-8606AD63C449@gmail.com>
 <7915D7A7-6CB7-43E8-90A4-6935E1569E32@serokell.io>
Message-ID: <899CC70F-195B-41D7-898D-5D9950D08A30@gmail.com>

Thanks once again for your detailed analysis, it's really helpful.
Especially the forall example - I did try constructing some string that would parse, but I was shooting in the dark.

Best,
Csongor

> On 29 Aug 2020, at 09:05, Vladislav Zavialov <vladislav at serokell.io> wrote:
> 
> The lexer produces only as many tokens as the parser requires. In the ‘lexerDbg’ dump that you included in the message, there were these lines:
> 
>  token: ITvarid "m"
>  token: ITvarid "b"
>  token: ITsemi
> 
> So I knew that the parser consumed the entire string, up to the virtual semicolon. I also recognized the parse error as the one produced by ‘happy’ rather than by a later validation pass. So even though the parser consumed the entire string, it failed. Therefore, it didn’t expect this string to end so abruptly, it expected it to continue.
> 
> But what did it expect to find? To figure it out, we need to know which grammar production is involved in the failure. The only grammar production that could’ve consumed the ‘->’ PREFIX_AT sequence successfully and proceed to process the rest of the string is this one:
> 
>   btype '->' PREFIX_AT btype ctype
> 
> By inspecting the definitions of ‘btype’ and ‘ctype’, one can see that neither of those accept the empty string, and both of those accept type-level function application. Thus it’s possible that ‘btype’ consumed “m b” as an application, and ‘ctype’ failed because it didn’t accept the remaining empty string:
> 
>  btype = “m b”
>  ctype = parse error (nothing to consume)
> 
> But what you wanted instead was:
> 
>  btype = “m”
>  ctype = “b”
> 
> The solution is to use ‘atype’ instead of ‘btype’, as ‘atype’ does not accept type-level application.
> 
> By the way, there’s also the input string on which the original grammar would’ve succeeded (or at least I think so):
> 
>  test :: a -> @m forall b. b
>  test = undefined
> 
> That’s because ‘btype’ wouldn’t have consumed the ‘forall’, it would’ve stopped at this point. And then ‘ctype’ could’ve consumed “forall b. b”.
> 
> I don’t think there’s a parser equivalent of -ddump-tc-trace. You’ll need to figure this stuff out by reading the grammar and keeping in mind that ‘happy’ generates a shift-reduce parser that does not backtrack. The ‘lexerDbg’ output is useful to see how far the parser got. And there’s also this command in case you want to go low level and inspect the state machine generated by ‘happy’:
> 
>    happy -agc --strict compiler/GHC/Parser.y -idetailed-info
> 
> Hope this helps,
> - Vlad
> 
>> On 29 Aug 2020, at 10:16, Csongor Kiss <kiss.csongor.kiss at gmail.com> wrote:
>> 
>> Thanks a lot Vlad and Shayne, that indeed did the trick!
>> 
>> Out of curiosity, how could I have figured out that this was the culprit? The parse
>> error I got was a bit puzzling, and I couldn't find any flags that would give more information
>> (I think I was looking for the parser equivalent of -ddump-tc-trace).
>> 
>> Best,
>> Csongor
> 


From allbery.b at gmail.com  Sat Aug 29 11:42:37 2020
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 29 Aug 2020 07:42:37 -0400
Subject: Parsing funny arrows
In-Reply-To: <AF59BBEF-B81A-4FF9-846F-8606AD63C449@gmail.com>
References: <921588CB-1578-46A8-8ED7-0100DEDD7883@gmail.com>
 <BF779FF6-7F54-4DF0-AB67-8BC0E31D48B6@serokell.io>
 <CAMsAzy9OEAKYm1oLZXUzNiw+wAnwLb==A=_VQXYSaYBuyOKCPA@mail.gmail.com>
 <CAMsAzy9+5vjzM=7qRRaecd0MAqm3LANudiW+VTyfXu7A0_VnCQ@mail.gmail.com>
 <AF59BBEF-B81A-4FF9-846F-8606AD63C449@gmail.com>
Message-ID: <CAKFCL4Wqdq8Cx0czvVkVsxq_BCzZxB++dw0vtGSK9fL4QFHZJQ@mail.gmail.com>

Another way to figure it out is the shift/reduce conflict on @, which tells
you it had two ways to recognize it. "Reduce" here means returning to your
parser rule, so "shift" means btype wanted to recognize the @. Inspecting
btype would then have shown that it was looking for a type application.

On Sat, Aug 29, 2020, 03:17 Csongor Kiss <kiss.csongor.kiss at gmail.com>
wrote:

> Thanks a lot Vlad and Shayne, that indeed did the trick!
>
> Out of curiosity, how could I have figured out that this was the culprit?
> The parse
> error I got was a bit puzzling, and I couldn't find any flags that would
> give more information
> (I think I was looking for the parser equivalent of -ddump-tc-trace).
>
> Best,
> Csongor
>
> On 29 Aug 2020, at 00:51, Shayne Fletcher <shayne.fletcher.50 at gmail.com>
> wrote:
>
>
>
> On Fri, Aug 28, 2020 at 7:48 PM Shayne Fletcher <
> shayne.fletcher.50 at gmail.com> wrote:
>
>>
>>
>> On Fri, Aug 28, 2020 at 7:38 PM Vladislav Zavialov <vladislav at serokell.io>
>> wrote:
>>
>>> Hi Csongor,
>>>
>>> I believe the reason for this failure is that  a -> @m b  gets parsed
>>> as  a -> @(m b).
>>> Why is that? Because a ‘btype’ includes type-level application.
>>>
>>> If you replace the ‘btype’ after PREFIX_AT with an ‘atype’, this
>>> particular issue should go away. At least that’s my hypothesis, I haven’t
>>> tested it.
>>>
>>>
>> I confirm that this is correct and with that change the example string
>> reduces as hoped.
>>
>>
>> - Vlad
>>>
>>
> Also, with that correction there are no new shift/reduce conflicts. The
> original rule gave rise to 3.
>
> --
> Shayne Fletcher
>
>
> _______________________________________________
> 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/20200829/4aeed3b8/attachment.html>

From vladislav at serokell.io  Sat Aug 29 14:40:27 2020
From: vladislav at serokell.io (Vladislav Zavialov)
Date: Sat, 29 Aug 2020 17:40:27 +0300
Subject: Parsing funny arrows
In-Reply-To: <CAKFCL4Wqdq8Cx0czvVkVsxq_BCzZxB++dw0vtGSK9fL4QFHZJQ@mail.gmail.com>
References: <921588CB-1578-46A8-8ED7-0100DEDD7883@gmail.com>
 <BF779FF6-7F54-4DF0-AB67-8BC0E31D48B6@serokell.io>
 <CAMsAzy9OEAKYm1oLZXUzNiw+wAnwLb==A=_VQXYSaYBuyOKCPA@mail.gmail.com>
 <CAMsAzy9+5vjzM=7qRRaecd0MAqm3LANudiW+VTyfXu7A0_VnCQ@mail.gmail.com>
 <AF59BBEF-B81A-4FF9-846F-8606AD63C449@gmail.com>
 <CAKFCL4Wqdq8Cx0czvVkVsxq_BCzZxB++dw0vtGSK9fL4QFHZJQ@mail.gmail.com>
Message-ID: <955E9420-7BAC-4D0A-9450-EE28E6D52387@serokell.io>

Hi Brandon, I’m afraid your analysis is not entirely correct. The shift/reduce conflict is not on @ but after it.

- Vlad

> On 29 Aug 2020, at 14:42, Brandon Allbery <allbery.b at gmail.com> wrote:
> 
> Another way to figure it out is the shift/reduce conflict on @, which tells you it had two ways to recognize it. "Reduce" here means returning to your parser rule, so "shift" means btype wanted to recognize the @. Inspecting btype would then have shown that it was looking for a type application.

From alan.zimm at gmail.com  Sun Aug 30 13:35:50 2020
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sun, 30 Aug 2020 14:35:50 +0100
Subject: HsPragTick
Message-ID: <CANma=H_x6rxLCmH+Cz1B3wAN-j-=oL_DPjmmgWhg2thJ-d9Uig@mail.gmail.com>

I am working through the API Annotations, and have come across HsPragTick.

In source it appears as

  c = {-# GENERATED "foobar" 1 : 2  -  3 :   4 #-} 0.00

But it does not seem to be used anywhere. It is passed through for renaming
and type checking, and Coverage.hs uses it as

addTickHsExpr (HsPragE _ HsPragTick{} (L pos e0)) = do
    e2 <- allocTickBox (ExpBox False) False False (locA pos) $
                addTickHsExpr e0
    return $ unLoc e2

So if it is used at all, the contents are ignored.

Can it be removed?

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

From moritz.angermann at gmail.com  Mon Aug 31 07:54:16 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 31 Aug 2020 15:54:16 +0800
Subject: Creative ideas on how to debug heap corruption
Message-ID: <CAKfdd-w9M6i9PHCnAxUfziEMBH__dyX-JZv8w0_jd9Q7HRr9Kg@mail.gmail.com>

Hi there!

as some of you may know, I've been working on an aarch64 native code
generator.  Now I've hit a situation where my stage2 compiler somehow
corrupts my heap.  Initially I thought this would likely be missing memory
barriers, however they are emitted.  This doesn't mean it can't be, but at
least it's not as simple as "they are just missing".

The crashes I see are non deterministic, in fact I sometimes even manage
to compile a Hello World module, without crashes.  Other times it crashes
with unknown closure errors or it just crashes.  But it always crashes
during GC.  Changing the nursery size make it crasha bit more frequent,
but nothing obvious sticks out yet.

If anyone has some create ideas, I'd love to hear them.  I've been wondering
if just logging allocations (offset, range, type) would help figuring out
what we
expected to be there; and then maybe try to break on the allocation, (and
subsequent writes).

I'm sure some have been down this road before.

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

From benl at ouroborus.net  Mon Aug 31 09:00:16 2020
From: benl at ouroborus.net (Ben Lippmeier)
Date: Mon, 31 Aug 2020 19:00:16 +1000
Subject: Creative ideas on how to debug heap corruption
In-Reply-To: <CAKfdd-w9M6i9PHCnAxUfziEMBH__dyX-JZv8w0_jd9Q7HRr9Kg@mail.gmail.com>
References: <CAKfdd-w9M6i9PHCnAxUfziEMBH__dyX-JZv8w0_jd9Q7HRr9Kg@mail.gmail.com>
Message-ID: <89C6E06D-E58F-4F05-AD9E-0022502F9185@ouroborus.net>



> On 31 Aug 2020, at 5:54 pm, Moritz Angermann <moritz.angermann at gmail.com> wrote:
> 
> If anyone has some create ideas, I'd love to hear them.  I've been wondering
> if just logging allocations (offset, range, type) would help figuring out what we
> expected to be there; and then maybe try to break on the allocation, (and
> subsequent writes).
> 
> I'm sure some have been down this road before. 

Force a GC before every allocation, and make the GC check the validity of the objects before it moves anything. I think this used to be possible by compiling the runtime system in debug mode.

The usual pain of heap corruption is that once the heap is corrupted it may be several GC cycles before you get the actual crash, and in the meantime the objects have all been moved around. The GC walks over all the objects by nature, so get it to validate the heap every time it does, then force it to run as often as you possibly can.

A user space approach is to use a library like vacuum or packman that also walks over the heap objects directly.

http://hackage.haskell.org/package/vacuum-2.2.0.0/docs/GHC-Vacuum.html
https://hackage.haskell.org/package/packman

Ben.




From ryan.gl.scott at gmail.com  Mon Aug 31 14:03:07 2020
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Mon, 31 Aug 2020 10:03:07 -0400
Subject: HsPragTick
Message-ID: <CADdQpRBaAX11x_kBsyyFAy_k8q5HCufsKAVJKManE2Ev211cng@mail.gmail.com>

I think that HsPragTick is unused as of [1]. In fact, I was under the
impression that [1] removed HsPragTick entirely (as the commit message)
would suggest, but upon further inspection, that doesn't appear to be the
case. Vlad, do you recall why HsPragTick was kept around?

Ryan S.
-----
[1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2154
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200831/4d6da96a/attachment.html>

From vladislav at serokell.io  Mon Aug 31 14:07:20 2020
From: vladislav at serokell.io (Vladislav Zavialov)
Date: Mon, 31 Aug 2020 17:07:20 +0300
Subject: HsPragTick
In-Reply-To: <CADdQpRBaAX11x_kBsyyFAy_k8q5HCufsKAVJKManE2Ev211cng@mail.gmail.com>
References: <CADdQpRBaAX11x_kBsyyFAy_k8q5HCufsKAVJKManE2Ev211cng@mail.gmail.com>
Message-ID: <CAGL=qfFZmFaO1yW_C36cJ_nRmjpFdhxUM-e9_CAnNBuSLGCN_A@mail.gmail.com>

I was under impression it was somehow related to HPC. Since I'm not
sufficiently familiar with HPC's inner workings, I kept it around just to
be safe.

- Vlad

On Mon, Aug 31, 2020, 17:03 Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> I think that HsPragTick is unused as of [1]. In fact, I was under the
> impression that [1] removed HsPragTick entirely (as the commit message)
> would suggest, but upon further inspection, that doesn't appear to be the
> case. Vlad, do you recall why HsPragTick was kept around?
>
> Ryan S.
> -----
> [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2154
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200831/0573b96f/attachment.html>

From csaba.hruska at gmail.com  Mon Aug 31 14:07:34 2020
From: csaba.hruska at gmail.com (Csaba Hruska)
Date: Mon, 31 Aug 2020 16:07:34 +0200
Subject: Creative ideas on how to debug heap corruption
In-Reply-To: <89C6E06D-E58F-4F05-AD9E-0022502F9185@ouroborus.net>
References: <CAKfdd-w9M6i9PHCnAxUfziEMBH__dyX-JZv8w0_jd9Q7HRr9Kg@mail.gmail.com>
 <89C6E06D-E58F-4F05-AD9E-0022502F9185@ouroborus.net>
Message-ID: <CANjChEoY=Y1XYV9jNkb+qn3ypV3vrHWu9dtChgDmA-wC8D-HxA@mail.gmail.com>

Dump the whole heap into file during GC traversal or taking the whole
allocated area. hmm, maybe this is the same as core dump.

On Mon, Aug 31, 2020 at 11:00 AM Ben Lippmeier <benl at ouroborus.net> wrote:

>
>
> > On 31 Aug 2020, at 5:54 pm, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
> >
> > If anyone has some create ideas, I'd love to hear them.  I've been
> wondering
> > if just logging allocations (offset, range, type) would help figuring
> out what we
> > expected to be there; and then maybe try to break on the allocation, (and
> > subsequent writes).
> >
> > I'm sure some have been down this road before.
>
> Force a GC before every allocation, and make the GC check the validity of
> the objects before it moves anything. I think this used to be possible by
> compiling the runtime system in debug mode.
>
> The usual pain of heap corruption is that once the heap is corrupted it
> may be several GC cycles before you get the actual crash, and in the
> meantime the objects have all been moved around. The GC walks over all the
> objects by nature, so get it to validate the heap every time it does, then
> force it to run as often as you possibly can.
>
> A user space approach is to use a library like vacuum or packman that also
> walks over the heap objects directly.
>
> http://hackage.haskell.org/package/vacuum-2.2.0.0/docs/GHC-Vacuum.html
> https://hackage.haskell.org/package/packman
>
> Ben.
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200831/f43c4446/attachment.html>

From george.colpitts at gmail.com  Mon Aug 31 14:17:22 2020
From: george.colpitts at gmail.com (George Colpitts)
Date: Mon, 31 Aug 2020 11:17:22 -0300
Subject: Creative ideas on how to debug heap corruption
In-Reply-To: <CANjChEoY=Y1XYV9jNkb+qn3ypV3vrHWu9dtChgDmA-wC8D-HxA@mail.gmail.com>
References: <CAKfdd-w9M6i9PHCnAxUfziEMBH__dyX-JZv8w0_jd9Q7HRr9Kg@mail.gmail.com>
 <89C6E06D-E58F-4F05-AD9E-0022502F9185@ouroborus.net>
 <CANjChEoY=Y1XYV9jNkb+qn3ypV3vrHWu9dtChgDmA-wC8D-HxA@mail.gmail.com>
Message-ID: <CAB-d4A7fqSGWir8YtPnsUOWDLruvBmhV9rZ3r8uNRKy5vhg5FQ@mail.gmail.com>

I assume you're familiar with the following from
https://www.aosabook.org/en/ghc.html and that this facility is still there.
Just in case you are not:

So, the debug RTS has an optional mode that we call *sanity checking*.
Sanity checking enables all kinds of expensive assertions, and can make the
program run many times more slowly. In particular, sanity checking runs a
full scan of the heap to check for dangling pointers (amongst other
things), before *and* after every GC. The first job when investigating a
runtime crash is to run the program with sanity checking turned on;
sometimes this will catch the invariant violation well before the program
actually crashes.


On Mon, Aug 31, 2020 at 11:08 AM Csaba Hruska <csaba.hruska at gmail.com>
wrote:

> Dump the whole heap into file during GC traversal or taking the whole
> allocated area. hmm, maybe this is the same as core dump.
>
> On Mon, Aug 31, 2020 at 11:00 AM Ben Lippmeier <benl at ouroborus.net> wrote:
>
>>
>>
>> > On 31 Aug 2020, at 5:54 pm, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>> >
>> > If anyone has some create ideas, I'd love to hear them.  I've been
>> wondering
>> > if just logging allocations (offset, range, type) would help figuring
>> out what we
>> > expected to be there; and then maybe try to break on the allocation,
>> (and
>> > subsequent writes).
>> >
>> > I'm sure some have been down this road before.
>>
>> Force a GC before every allocation, and make the GC check the validity of
>> the objects before it moves anything. I think this used to be possible by
>> compiling the runtime system in debug mode.
>>
>> The usual pain of heap corruption is that once the heap is corrupted it
>> may be several GC cycles before you get the actual crash, and in the
>> meantime the objects have all been moved around. The GC walks over all the
>> objects by nature, so get it to validate the heap every time it does, then
>> force it to run as often as you possibly can.
>>
>> A user space approach is to use a library like vacuum or packman that
>> also walks over the heap objects directly.
>>
>> http://hackage.haskell.org/package/vacuum-2.2.0.0/docs/GHC-Vacuum.html
>> https://hackage.haskell.org/package/packman
>>
>> Ben.
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200831/e067ce02/attachment.html>

From george.colpitts at gmail.com  Mon Aug 31 14:18:34 2020
From: george.colpitts at gmail.com (George Colpitts)
Date: Mon, 31 Aug 2020 11:18:34 -0300
Subject: Creative ideas on how to debug heap corruption
In-Reply-To: <CAB-d4A7fqSGWir8YtPnsUOWDLruvBmhV9rZ3r8uNRKy5vhg5FQ@mail.gmail.com>
References: <CAKfdd-w9M6i9PHCnAxUfziEMBH__dyX-JZv8w0_jd9Q7HRr9Kg@mail.gmail.com>
 <89C6E06D-E58F-4F05-AD9E-0022502F9185@ouroborus.net>
 <CANjChEoY=Y1XYV9jNkb+qn3ypV3vrHWu9dtChgDmA-wC8D-HxA@mail.gmail.com>
 <CAB-d4A7fqSGWir8YtPnsUOWDLruvBmhV9rZ3r8uNRKy5vhg5FQ@mail.gmail.com>
Message-ID: <CAB-d4A755GVo1jUU=Zo+SitMVV=2r16SNQ-81hiYEgoK-zP+Uw@mail.gmail.com>

+Moritz

On Mon, Aug 31, 2020 at 11:17 AM George Colpitts <george.colpitts at gmail.com>
wrote:

> I assume you're familiar with the following from
> https://www.aosabook.org/en/ghc.html and that this facility is still
> there. Just in case you are not:
>
> So, the debug RTS has an optional mode that we call *sanity checking*.
> Sanity checking enables all kinds of expensive assertions, and can make the
> program run many times more slowly. In particular, sanity checking runs a
> full scan of the heap to check for dangling pointers (amongst other
> things), before *and* after every GC. The first job when investigating a
> runtime crash is to run the program with sanity checking turned on;
> sometimes this will catch the invariant violation well before the program
> actually crashes.
>
>
> On Mon, Aug 31, 2020 at 11:08 AM Csaba Hruska <csaba.hruska at gmail.com>
> wrote:
>
>> Dump the whole heap into file during GC traversal or taking the whole
>> allocated area. hmm, maybe this is the same as core dump.
>>
>> On Mon, Aug 31, 2020 at 11:00 AM Ben Lippmeier <benl at ouroborus.net>
>> wrote:
>>
>>>
>>>
>>> > On 31 Aug 2020, at 5:54 pm, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>> >
>>> > If anyone has some create ideas, I'd love to hear them.  I've been
>>> wondering
>>> > if just logging allocations (offset, range, type) would help figuring
>>> out what we
>>> > expected to be there; and then maybe try to break on the allocation,
>>> (and
>>> > subsequent writes).
>>> >
>>> > I'm sure some have been down this road before.
>>>
>>> Force a GC before every allocation, and make the GC check the validity
>>> of the objects before it moves anything. I think this used to be possible
>>> by compiling the runtime system in debug mode.
>>>
>>> The usual pain of heap corruption is that once the heap is corrupted it
>>> may be several GC cycles before you get the actual crash, and in the
>>> meantime the objects have all been moved around. The GC walks over all the
>>> objects by nature, so get it to validate the heap every time it does, then
>>> force it to run as often as you possibly can.
>>>
>>> A user space approach is to use a library like vacuum or packman that
>>> also walks over the heap objects directly.
>>>
>>> http://hackage.haskell.org/package/vacuum-2.2.0.0/docs/GHC-Vacuum.html
>>> https://hackage.haskell.org/package/packman
>>>
>>> Ben.
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200831/0eadd5c9/attachment.html>

From csaba.hruska at gmail.com  Mon Aug 31 14:29:19 2020
From: csaba.hruska at gmail.com (Csaba Hruska)
Date: Mon, 31 Aug 2020 16:29:19 +0200
Subject: Creative ideas on how to debug heap corruption
In-Reply-To: <CAB-d4A755GVo1jUU=Zo+SitMVV=2r16SNQ-81hiYEgoK-zP+Uw@mail.gmail.com>
References: <CAKfdd-w9M6i9PHCnAxUfziEMBH__dyX-JZv8w0_jd9Q7HRr9Kg@mail.gmail.com>
 <89C6E06D-E58F-4F05-AD9E-0022502F9185@ouroborus.net>
 <CANjChEoY=Y1XYV9jNkb+qn3ypV3vrHWu9dtChgDmA-wC8D-HxA@mail.gmail.com>
 <CAB-d4A7fqSGWir8YtPnsUOWDLruvBmhV9rZ3r8uNRKy5vhg5FQ@mail.gmail.com>
 <CAB-d4A755GVo1jUU=Zo+SitMVV=2r16SNQ-81hiYEgoK-zP+Uw@mail.gmail.com>
Message-ID: <CANjChEpNOXnPeW=kfR2Q+ER2oRiFtft3gkykT2++NGuiH9DJLg@mail.gmail.com>

Fuzzing:

   1. generate simple random stg programs
   2. compile and run with RTS sanity checking enabled
   3. compare the program result between different backends

The fuzzer should cover all codegen cases and all code in RTS. Maybe this
could be checked by the existing tools.

On Mon, Aug 31, 2020 at 4:19 PM George Colpitts <george.colpitts at gmail.com>
wrote:

> +Moritz
>
> On Mon, Aug 31, 2020 at 11:17 AM George Colpitts <
> george.colpitts at gmail.com> wrote:
>
>> I assume you're familiar with the following from
>> https://www.aosabook.org/en/ghc.html and that this facility is still
>> there. Just in case you are not:
>>
>> So, the debug RTS has an optional mode that we call *sanity checking*.
>> Sanity checking enables all kinds of expensive assertions, and can make the
>> program run many times more slowly. In particular, sanity checking runs a
>> full scan of the heap to check for dangling pointers (amongst other
>> things), before *and* after every GC. The first job when investigating a
>> runtime crash is to run the program with sanity checking turned on;
>> sometimes this will catch the invariant violation well before the program
>> actually crashes.
>>
>>
>> On Mon, Aug 31, 2020 at 11:08 AM Csaba Hruska <csaba.hruska at gmail.com>
>> wrote:
>>
>>> Dump the whole heap into file during GC traversal or taking the whole
>>> allocated area. hmm, maybe this is the same as core dump.
>>>
>>> On Mon, Aug 31, 2020 at 11:00 AM Ben Lippmeier <benl at ouroborus.net>
>>> wrote:
>>>
>>>>
>>>>
>>>> > On 31 Aug 2020, at 5:54 pm, Moritz Angermann <
>>>> moritz.angermann at gmail.com> wrote:
>>>> >
>>>> > If anyone has some create ideas, I'd love to hear them.  I've been
>>>> wondering
>>>> > if just logging allocations (offset, range, type) would help figuring
>>>> out what we
>>>> > expected to be there; and then maybe try to break on the allocation,
>>>> (and
>>>> > subsequent writes).
>>>> >
>>>> > I'm sure some have been down this road before.
>>>>
>>>> Force a GC before every allocation, and make the GC check the validity
>>>> of the objects before it moves anything. I think this used to be possible
>>>> by compiling the runtime system in debug mode.
>>>>
>>>> The usual pain of heap corruption is that once the heap is corrupted it
>>>> may be several GC cycles before you get the actual crash, and in the
>>>> meantime the objects have all been moved around. The GC walks over all the
>>>> objects by nature, so get it to validate the heap every time it does, then
>>>> force it to run as often as you possibly can.
>>>>
>>>> A user space approach is to use a library like vacuum or packman that
>>>> also walks over the heap objects directly.
>>>>
>>>> http://hackage.haskell.org/package/vacuum-2.2.0.0/docs/GHC-Vacuum.html
>>>> https://hackage.haskell.org/package/packman
>>>>
>>>> Ben.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200831/70ff27a0/attachment.html>

From arnaud.spiwack at tweag.io  Mon Aug 31 14:34:05 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 31 Aug 2020 16:34:05 +0200
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
Message-ID: <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>

I’ve been pointed to https://github.com/ghc-proposals/ghc-proposals/pull/35
where this was debated a few years ago. With much of the same arguments as
today.

Simon Marlow said

making an unboxed tuple binding lazy by default seems to be intuitively the
> wrong choice. I guarantee I would get tripped up by this! Giving unboxed
> tuples an implicit bang seems reasonable to me.
>
I can share that I got tripped by it. And so were other members of my team.

That being said, Richard seemed to feel rather strongly about this one.
Richard, do you still agree with your then position that let (#x, y#) = …
being a lazy pattern (hence implicitly boxes the pair) is the right
semantics?

On Fri, Aug 28, 2020 at 8:26 PM chessai <chessai1996 at gmail.com> wrote:

> Arnaud,
>
> I have dealt with this in the past and find the laziness extremely
> counterintuitive and never wanted. Every time I have let-bound an unboxed
> tuple, I have never wanted that boxing to occur. Perhaps there is a good
> reason this is the case but I wish it would change.
>
> On Fri, Aug 28, 2020, 08:26 Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>> Hi Carter,
>>
>> We are using let !(#x,y#) = … actually. Having the strict behaviour is
>> not particularly difficult. You can even use case … of (#x, y#) ->…
>> directly, it’s not too bad. My complaint, as it were, is solely about the
>> potential for mistakes.
>>
>> On Fri, Aug 28, 2020 at 3:20 PM Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> Have you tried using do notation for bindings you want to keep strict,
>>> with Eg the identity monad?  That doesn’t address  the design critique but
>>> gives you a path forward ?
>>>
>>> I do agree that the semantics / default recursivity Of let bindings  can
>>> be inappropriate for non recursive code , but would any other non uniform
>>> semantics or optimization be safe?
>>>
>>> On Fri, Aug 28, 2020 at 9:05 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>>
>>>> I discovered the hard way, yesterday, that lazy let pattern
>>>> matching is allowed on unboxed tuples. And that it implicitly reboxes
>>>> the pattern.
>>>>
>>>>
>>>> Here is how the manual describes it, from the relevant section
>>>> <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-UnboxedTuples>
>>>> :
>>>>
>>>>
>>>>
>>>>
>>>> You can have an unboxed tuple in a pattern binding, thus
>>>>
>>>>
>>>> f x = let (# p,q #) = h x in ..body..
>>>>
>>>>
>>>>
>>>> If the types of p and q are not unboxed, the resulting binding is lazy
>>>> like any other Haskell pattern binding. The above example desugars like
>>>> this:
>>>>
>>>>
>>>> f x = let t = case h x of { (# p,q #) -> (p,q) }
>>>>
>>>>           p = fst t
>>>>
>>>>           q = snd t
>>>>
>>>>       in ..body..
>>>>
>>>>
>>>>
>>>> Indeed, the bindings can even be recursive.
>>>>
>>>>
>>>>
>>>>
>>>> Notice how h x is lazily bound, hence won’t necessarily be run when
>>>> body is forced. as opposed to if I had written, for instance,
>>>>
>>>>
>>>> let u = hx
>>>>
>>>> in ..body..
>>>>
>>>>
>>>>
>>>> My question is: are we happy with this? I did find this extremely
>>>> surprising. If I’m using unboxed tuples, it’s because I want to
>>>> guarantee to myself a strict, unboxed behaviour. But a very subtle
>>>> syntactic detail seems to break this expectation for me. My
>>>> expectation would be that I would need to explicitly rebox things
>>>> before they get lazy again.
>>>>
>>>>
>>>> I find that this behaviour invites trouble. But you may disagree. Let
>>>> me know!
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> 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/20200831/788b5b4f/attachment.html>

From John.Ericson at Obsidian.Systems  Mon Aug 31 17:48:55 2020
From: John.Ericson at Obsidian.Systems (John Cotton Ericson)
Date: Mon, 31 Aug 2020 13:48:55 -0400
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
Message-ID: <7934b789-45e7-060b-d51d-d9cf53d011a7@Obsidian.Systems>

I haven't used unboxed tuples enough to perhaps feel the pain, but on 
paper the current design makes sense to me. The laziness of the binding 
is suppose to have to do with the runtime rep of the binding itself, not 
any enclosing pattern.

For example take

     {-# LANGUAGE ScopedTypeVariables #-}
     {-# LANGUAGE MagicHash #-}

     import GHC.Base

     data Foo = Foo Int# Int#

     main = pure ()
         where Foo x y = Foo undefined undefined

This program will fail even though x and y are unused.

While this principle may not match how this stuff is used in practice, 
the alternative of making the strictness of the bindings depend on more 
than their runtime reps seems less-local / more ad-hoc to me.

John

On 8/31/20 10:34 AM, Spiwack, Arnaud wrote:
>
> I’ve been pointed to 
> https://github.com/ghc-proposals/ghc-proposals/pull/35 where this was 
> debated a few years ago. With much of the same arguments as today.
>
> Simon Marlow said
>
>     making an unboxed tuple binding lazy by default seems to be
>     intuitively the wrong choice. I guarantee I would get tripped up
>     by this! Giving unboxed tuples an implicit bang seems reasonable
>     to me.
>
> I can share that I got tripped by it. And so were other members of my 
> team.
>
> That being said, Richard seemed to feel rather strongly about this 
> one. Richard, do you still agree with your then position that |let 
> (#x, y#) = …| being a lazy pattern (hence implicitly boxes the pair) 
> is the right semantics?
>
>
> On Fri, Aug 28, 2020 at 8:26 PM chessai <chessai1996 at gmail.com 
> <mailto:chessai1996 at gmail.com>> wrote:
>
>     Arnaud,
>
>     I have dealt with this in the past and find the laziness extremely
>     counterintuitive and never wanted. Every time I have let-bound an
>     unboxed tuple, I have never wanted that boxing to occur. Perhaps
>     there is a good reason this is the case but I wish it would change.
>
>     On Fri, Aug 28, 2020, 08:26 Spiwack, Arnaud
>     <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>
>         Hi Carter,
>
>         We are using |let !(#x,y#) = …| actually. Having the strict
>         behaviour is not particularly difficult. You can even use
>         |case … of (#x, y#) ->…| directly, it’s not too bad. My
>         complaint, as it were, is solely about the potential for mistakes.
>
>
>         On Fri, Aug 28, 2020 at 3:20 PM Carter Schonwald
>         <carter.schonwald at gmail.com
>         <mailto:carter.schonwald at gmail.com>> wrote:
>
>             Have you tried using do notation for bindings you want to
>             keep strict, with Eg the identity monad?  That doesn’t
>             address  the design critique but gives you a path forward ?
>
>             I do agree that the semantics / default recursivity Of let
>             bindings  can be inappropriate for non recursive code ,
>             but would any other non uniform semantics or optimization
>             be safe?
>
>             On Fri, Aug 28, 2020 at 9:05 AM Spiwack, Arnaud
>             <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>             wrote:
>
>                 Dear all,
>
>
>
>                 I discovered the hard way, yesterday, that lazy let
>                 pattern
>                 matching is allowed on unboxed tuples. And that it
>                 implicitly reboxes
>                 the pattern.
>
>
>
>                 Here is how the manual describes it, from the relevant
>                 section
>                 <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-UnboxedTuples>:
>
>
>
>
>
>                     You can have an unboxed tuple in a pattern
>                     binding, thus
>
>
>
>                     |f x = let (# p,q #) = h x in ..body.. |
>
>
>
>                     If the types of |p| and |q| are not unboxed, the
>                     resulting binding is lazy like any other Haskell
>                     pattern binding. The above example desugars like this:
>
>
>
>                     |f x = let t = case h x of { (# p,q #) -> (p,q) }
>                     p = fst t q = snd t in ..body.. |
>
>
>
>                     Indeed, the bindings can even be recursive.
>
>
>
>
>
>                 Notice how |h x| is lazily bound, hence won’t
>                 necessarily be run when
>                 |body| is forced. as opposed to if I had written, for
>                 instance,
>
>
>
>                 |let u = hx in ..body.. |
>
>
>
>                 My question is: are we happy with this? I did find
>                 this extremely
>                 surprising. If I’m using unboxed tuples, it’s because
>                 I want to
>                 guarantee to myself a strict, unboxed behaviour. But a
>                 very subtle
>                 syntactic detail seems to break this expectation for
>                 me. My
>                 expectation would be that I would need to explicitly
>                 rebox things
>                 before they get lazy again.
>
>
>
>                 I find that this behaviour invites trouble. But you
>                 may disagree. Let
>                 me know!
>
>
>
>
>
>                 _______________________________________________
>
>                 ghc-devs mailing list
>
>                 ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>
>                 http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>         _______________________________________________
>         ghc-devs mailing list
>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200831/c71b9741/attachment-0001.html>

From csaba.hruska at gmail.com  Mon Aug 31 18:30:10 2020
From: csaba.hruska at gmail.com (Csaba Hruska)
Date: Mon, 31 Aug 2020 20:30:10 +0200
Subject: WebUI for GHC/Haskell tooling (eventlog)
Message-ID: <CANjChEqhfmbN_BU1cm_ja0fWMu1Sgp0JsrAVdvXucx_W3e6gwA@mail.gmail.com>

Hello,

I've written a blog post <https://www.patreon.com/posts/41065262> about my
WebUI based eventlog related tool.
It is also related to eventlog2html and ghc-debug.
I'm interested in your opinion and ideas related to ghc debug/profiling
tooling.
If you have time please read the post and it would be great to hear some
positive or negative feedback from you. It would be great to discuss this
topic with you.

Thanks,
Csaba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200831/2a11c871/attachment.html>

From rae at richarde.dev  Mon Aug 31 19:14:22 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 31 Aug 2020 19:14:22 +0000
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
Message-ID: <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>



> On Aug 31, 2020, at 10:34 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> That being said, Richard seemed to feel rather strongly about this one. Richard, do you still agree with your then position that let (#x, y#) = … being a lazy pattern (hence implicitly boxes the pair) is the right semantics?

I admit I don't feel as strongly any more. My argument in that thread was from the standpoint of a language designer: there is really no reason, a priori, for an unboxed-tuple binding to be strict. What controls strictness is whether the bound variables are of unlifted type. However, I'm currently in more sympathy with language users, who (for whatever reason) seem to think that bindings with #s in them should be strict. (I have this intuition myself, even though it's not quite warranted on technical grounds.)

What do we think of

> pattern Unl x y = (# x, y #)
> 
> ex1, ex2 :: ()
> ex1 = let Unl x y = Unl undefined undefined in ()
> ex2 = let Unl x y = undefined in ()


? Today, both ex1 and ex2 evaluate to (). If we were to change the specification here, would we consider any unlifted-type pattern (where the type of the pattern itself is unlifted, independent of the type of any of its bound variables) to be banged? Or would it be a super-special case for unboxed tuples?

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

From rae at richarde.dev  Mon Aug 31 19:30:05 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 31 Aug 2020 19:30:05 +0000
Subject: COMPLETE pragmas
Message-ID: <010f017445ff7d3e-e5395db8-776e-412e-9a66-d12c8ae3177d-000000@us-east-2.amazonses.com>

Hi Sebastian,

I enjoyed your presentation last week at ICFP!

This thread (https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms) played out before you became so interested in pattern-match coverage. I'd be curious for your thoughts there -- do you agree with the conclusions in the thread?

My motivation for asking is https://github.com/conal/linalg/pull/54 (you don't need to read the whole thing), which can be boiled down to a request for a COMPLETE pragma that works at a polymorphic result type. (Or a COMPLETE pragma written in a module that is not the defining module for a pattern synonym.) https://gitlab.haskell.org/ghc/ghc/-/issues/14422 describes a similar, but even more challenging scenario.

Do you see any ways forward here?

Thanks!
Richard

From rae at richarde.dev  Mon Aug 31 19:57:30 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 31 Aug 2020 19:57:30 +0000
Subject: HsPragTick
In-Reply-To: <CAGL=qfFZmFaO1yW_C36cJ_nRmjpFdhxUM-e9_CAnNBuSLGCN_A@mail.gmail.com>
References: <CADdQpRBaAX11x_kBsyyFAy_k8q5HCufsKAVJKManE2Ev211cng@mail.gmail.com>
 <CAGL=qfFZmFaO1yW_C36cJ_nRmjpFdhxUM-e9_CAnNBuSLGCN_A@mail.gmail.com>
Message-ID: <010f017446189786-b22e0736-d570-478f-a800-4c0e6013602e-000000@us-east-2.amazonses.com>

I'm content with ripping it out and waiting to see if anyone complains. Without documentation or any obvious users, it seems hard to do otherwise.

That said, if you reading this have a better idea than we do about who uses {-# GENERATED ... #-} pragmas, do speak up!

Thanks,
Richard

> On Aug 31, 2020, at 10:07 AM, Vladislav Zavialov <vladislav at serokell.io> wrote:
> 
> I was under impression it was somehow related to HPC. Since I'm not sufficiently familiar with HPC's inner workings, I kept it around just to be safe.
> 
> - Vlad
> 
> On Mon, Aug 31, 2020, 17:03 Ryan Scott <ryan.gl.scott at gmail.com <mailto:ryan.gl.scott at gmail.com>> wrote:
> I think that HsPragTick is unused as of [1]. In fact, I was under the impression that [1] removed HsPragTick entirely (as the commit message) would suggest, but upon further inspection, that doesn't appear to be the case. Vlad, do you recall why HsPragTick was kept around?
> 
> Ryan S.
> -----
> [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2154 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2154>_______________________________________________
> 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/20200831/a16d3308/attachment.html>

From sgraf1337 at gmail.com  Mon Aug 31 20:23:16 2020
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Mon, 31 Aug 2020 22:23:16 +0200
Subject: COMPLETE pragmas
In-Reply-To: <010f017445ff7d3e-e5395db8-776e-412e-9a66-d12c8ae3177d-000000@us-east-2.amazonses.com>
References: <010f017445ff7d3e-e5395db8-776e-412e-9a66-d12c8ae3177d-000000@us-east-2.amazonses.com>
Message-ID: <CAAS+=P8_aOr+=bYM-s_JasR6sPjuVTPXU7OicS3sBNEA81cy7w@mail.gmail.com>

Hi Richard,

Am Mo., 31. Aug. 2020 um 21:30 Uhr schrieb Richard Eisenberg <
rae at richarde.dev>:

> Hi Sebastian,
>
> I enjoyed your presentation last week at ICFP!
>

Thank you :) I'm glad you liked it!

This thread (
> https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms)
> played out before you became so interested in pattern-match coverage. I'd
> be curious for your thoughts there -- do you agree with the conclusions in
> the thread?
>

I vaguely remember reading this thread. As you write there
<https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms#post9>

And, while I know it doesn't work today, what's wrong (in theory) with
>
> {-# COMPLETE LL #-}
>
> No types! (That's a rare thing for me to extol...)
>
> I feel I must be missing something here.
>

Without reading the whole thread, I think that solution is very possible.
The thread goes on to state that we currently attach COMPLETE sets to type
constructors, but that is only an implementational thing. I asked Matt (who
implemented it) somewhere and he said the only reason to attach it to type
constructors was because it was the easiest way to implement serialisation
to interface files.

The thread also mentions that type-directed works better for the
pattern-match checker. In fact I disagree; we have to thin out COMPLETE
sets all the time anyway when new type evidence comes up, for example. It's
quite a hassle to find all the COMPLETE sets of the type constructors a
given type can be "represented" (I mean equality modulo type family
reductions here) as. I'm pretty sure it's broken in multiple ways, as #18276
<https://gitlab.haskell.org/ghc/ghc/-/issues/18276> points out.

Disregarding a bit of busy work for implementing serialisation to interface
files, it's probably far simpler to give each COMPLETE set a Name/Unique
and refer to them from the pattern synonyms that mention them (we'd have to
get creative for orphans, though). The relation is quite like between a
type class instance and the type in its head. A more worked example is
here: https://gitlab.haskell.org/ghc/ghc/-/issues/18277#note_287827

So, it's on my longer term TODO list to fix this.


> My motivation for asking is https://github.com/conal/linalg/pull/54 (you
> don't need to read the whole thing), which can be boiled down to a request
> for a COMPLETE pragma that works at a polymorphic result type. (Or a
> COMPLETE pragma written in a module that is not the defining module for a
> pattern synonym.) https://gitlab.haskell.org/ghc/ghc/-/issues/14422
> describes a similar, but even more challenging scenario.
>

I'll answer in the thread. (Oh, you also found #14422.) I think the
approach above will also fix #14422.

>
> Do you see any ways forward here?
>
.

>
> Thanks!
> Richard


Maybe I'll give it a try tomorrow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200831/fc365d6b/attachment.html>

From rae at richarde.dev  Mon Aug 31 21:29:10 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 31 Aug 2020 21:29:10 +0000
Subject: COMPLETE pragmas
In-Reply-To: <CAAS+=P8_aOr+=bYM-s_JasR6sPjuVTPXU7OicS3sBNEA81cy7w@mail.gmail.com>
References: <010f017445ff7d3e-e5395db8-776e-412e-9a66-d12c8ae3177d-000000@us-east-2.amazonses.com>
 <CAAS+=P8_aOr+=bYM-s_JasR6sPjuVTPXU7OicS3sBNEA81cy7w@mail.gmail.com>
Message-ID: <010f0174466c8088-93ed323f-9cdf-401a-9348-58e1c0adc1a6-000000@us-east-2.amazonses.com>

Hooray Sebastian!

Somehow, I knew cluing you into this conundrum would help find a solution. The approach you describe sounds quite plausible.

Yet: types *do* matter, of course. So, I suppose the trick is this: have the COMPLETE sets operate independent of types, but then use types in the PM-checker when determining impossible cases? And, about your idea for having pattern synonyms store pointers to their COMPLETE sets: I think data constructors can also participate. But maybe there is always at least one pattern synonym (which would be a reasonable restriction), so I guess you can look at the pattern-match as a whole and use the pattern synonym to find the relevant COMPLETE set(s).

Thanks for taking a look!
Richard

> On Aug 31, 2020, at 4:23 PM, Sebastian Graf <sgraf1337 at gmail.com> wrote:
> 
> Hi Richard,
> 
> Am Mo., 31. Aug. 2020 um 21:30 Uhr schrieb Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>>:
> Hi Sebastian,
> 
> I enjoyed your presentation last week at ICFP!
> 
> Thank you :) I'm glad you liked it!
> 
> This thread (https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms <https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms>) played out before you became so interested in pattern-match coverage. I'd be curious for your thoughts there -- do you agree with the conclusions in the thread?
> 
> I vaguely remember reading this thread. As you write there <https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms#post9>
> 
> And, while I know it doesn't work today, what's wrong (in theory) with
> 
> {-# COMPLETE LL #-}
> 
> No types! (That's a rare thing for me to extol...)
> 
> I feel I must be missing something here.
> 
> Without reading the whole thread, I think that solution is very possible. The thread goes on to state that we currently attach COMPLETE sets to type constructors, but that is only an implementational thing. I asked Matt (who implemented it) somewhere and he said the only reason to attach it to type constructors was because it was the easiest way to implement serialisation to interface files.
> 
> The thread also mentions that type-directed works better for the pattern-match checker. In fact I disagree; we have to thin out COMPLETE sets all the time anyway when new type evidence comes up, for example. It's quite a hassle to find all the COMPLETE sets of the type constructors a given type can be "represented" (I mean equality modulo type family reductions here) as. I'm pretty sure it's broken in multiple ways, as #18276 <https://gitlab.haskell.org/ghc/ghc/-/issues/18276> points out.
> 
> Disregarding a bit of busy work for implementing serialisation to interface files, it's probably far simpler to give each COMPLETE set a Name/Unique and refer to them from the pattern synonyms that mention them (we'd have to get creative for orphans, though). The relation is quite like between a type class instance and the type in its head. A more worked example is here: https://gitlab.haskell.org/ghc/ghc/-/issues/18277#note_287827 <https://gitlab.haskell.org/ghc/ghc/-/issues/18277#note_287827>
> 
> So, it's on my longer term TODO list to fix this.
> 
> 
> My motivation for asking is https://github.com/conal/linalg/pull/54 <https://github.com/conal/linalg/pull/54> (you don't need to read the whole thing), which can be boiled down to a request for a COMPLETE pragma that works at a polymorphic result type. (Or a COMPLETE pragma written in a module that is not the defining module for a pattern synonym.) https://gitlab.haskell.org/ghc/ghc/-/issues/14422 <https://gitlab.haskell.org/ghc/ghc/-/issues/14422> describes a similar, but even more challenging scenario.
> 
> I'll answer in the thread. (Oh, you also found #14422.) I think the approach above will also fix #14422.
> 
> Do you see any ways forward here?
> . 
> 
> Thanks!
> Richard
> 
> Maybe I'll give it a try tomorrow. 

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

From ekmett at gmail.com  Mon Aug 31 22:26:30 2020
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 31 Aug 2020 15:26:30 -0700
Subject: COMPLETE pragmas
In-Reply-To: <010f0174466c8088-93ed323f-9cdf-401a-9348-58e1c0adc1a6-000000@us-east-2.amazonses.com>
References: <010f017445ff7d3e-e5395db8-776e-412e-9a66-d12c8ae3177d-000000@us-east-2.amazonses.com>
 <CAAS+=P8_aOr+=bYM-s_JasR6sPjuVTPXU7OicS3sBNEA81cy7w@mail.gmail.com>
 <010f0174466c8088-93ed323f-9cdf-401a-9348-58e1c0adc1a6-000000@us-east-2.amazonses.com>
Message-ID: <CAJumaK8ARUvkU5R7sWHQgAoPHPreE29DwNoxrLs7xi9nU1hzpw@mail.gmail.com>

I'd be over the moon with happiness if I could hang COMPLETE pragmas on
polymorphic types.

I have 3 major issues with COMPLETE as it exists.

1.) Is what is mentioned here:

Examples for me come up when trying to build a completely unboxed 'linear'
library using backpack. In the end I want/need to supply a pattern synonym
that works over, say, all the 2d vector types, extracting their elements,
but right now I just get spammed by incomplete coverage warnings.

type family Elem t :: Type
class D2 where
  _V2 :: Iso' t (Elem t, Elem t)

pattern V2 :: D2 t => Elem t -> Elem t -> t
pattern V2 a b <- (view _V2 -> (a,b)) where
  V2 a b = review _V2 (a,b)

There is no way to hang a COMPLETE pragma on that.

2.) Another scenario that I'd really love to see supported with COMPLETE
pragmas is a way to use | notation with them like you can with MINIMAL
pragmas.

If you make smart constructors for a dozen constructors in your term type
(don't judge me!), you wind up needing 2^12 COMPLETE pragmas to describe
all the ways you might mix regular and start constructors today.

{# COMPLETE (Lam | LAM), (Var | VAR), ... #-}

would let you get away with a single such definition. This comes up when
you have some kind of monoid that acts on terms and you want to push it
down through
the syntax tree invisibly to the user. Explicit substitutions, shifts in
position in response to source code edits, etc.

3.) I had one other major usecase where I failed to be able to use a
COMPLETE pragma:

type Option a = (# a | (##) #)

pattern Some :: a -> Option a
pattern Some a = (# a | #)

pattern None :: Option a
pattern None = (# | (##) #)

{-# COMPLETE Some, None #-}

These worked _within_ a module, but was forgotten across module boundaries,
which forced me to rather drastically change the module structure of a
package, but it sounds a lot like the issue being discussed. No types to
hang it on in the interface file. With the ability to define unlifted
newtypes I guess this last one is less of a concern now?

-Edward

On Mon, Aug 31, 2020 at 2:29 PM Richard Eisenberg <rae at richarde.dev> wrote:

> Hooray Sebastian!
>
> Somehow, I knew cluing you into this conundrum would help find a solution.
> The approach you describe sounds quite plausible.
>
> Yet: types *do* matter, of course. So, I suppose the trick is this: have
> the COMPLETE sets operate independent of types, but then use types in the
> PM-checker when determining impossible cases? And, about your idea for
> having pattern synonyms store pointers to their COMPLETE sets: I think data
> constructors can also participate. But maybe there is always at least one
> pattern synonym (which would be a reasonable restriction), so I guess you
> can look at the pattern-match as a whole and use the pattern synonym to
> find the relevant COMPLETE set(s).
>
> Thanks for taking a look!
> Richard
>
> On Aug 31, 2020, at 4:23 PM, Sebastian Graf <sgraf1337 at gmail.com> wrote:
>
> Hi Richard,
>
> Am Mo., 31. Aug. 2020 um 21:30 Uhr schrieb Richard Eisenberg <
> rae at richarde.dev>:
>
>> Hi Sebastian,
>>
>> I enjoyed your presentation last week at ICFP!
>>
>
> Thank you :) I'm glad you liked it!
>
> This thread (
>> https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms)
>> played out before you became so interested in pattern-match coverage. I'd
>> be curious for your thoughts there -- do you agree with the conclusions in
>> the thread?
>>
>
> I vaguely remember reading this thread. As you write there
> <https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms#post9>
>
> And, while I know it doesn't work today, what's wrong (in theory) with
>>
>> {-# COMPLETE LL #-}
>>
>> No types! (That's a rare thing for me to extol...)
>>
>> I feel I must be missing something here.
>>
>
> Without reading the whole thread, I think that solution is very possible.
> The thread goes on to state that we currently attach COMPLETE sets to type
> constructors, but that is only an implementational thing. I asked Matt (who
> implemented it) somewhere and he said the only reason to attach it to type
> constructors was because it was the easiest way to implement serialisation
> to interface files.
>
> The thread also mentions that type-directed works better for the
> pattern-match checker. In fact I disagree; we have to thin out COMPLETE
> sets all the time anyway when new type evidence comes up, for example. It's
> quite a hassle to find all the COMPLETE sets of the type constructors a
> given type can be "represented" (I mean equality modulo type family
> reductions here) as. I'm pretty sure it's broken in multiple ways, as
> #18276 <https://gitlab.haskell.org/ghc/ghc/-/issues/18276> points out.
>
> Disregarding a bit of busy work for implementing serialisation to
> interface files, it's probably far simpler to give each COMPLETE set a
> Name/Unique and refer to them from the pattern synonyms that mention them
> (we'd have to get creative for orphans, though). The relation is quite like
> between a type class instance and the type in its head. A more worked
> example is here:
> https://gitlab.haskell.org/ghc/ghc/-/issues/18277#note_287827
>
> So, it's on my longer term TODO list to fix this.
>
>
>> My motivation for asking is https://github.com/conal/linalg/pull/54 (you
>> don't need to read the whole thing), which can be boiled down to a request
>> for a COMPLETE pragma that works at a polymorphic result type. (Or a
>> COMPLETE pragma written in a module that is not the defining module for a
>> pattern synonym.) https://gitlab.haskell.org/ghc/ghc/-/issues/14422
>> describes a similar, but even more challenging scenario.
>>
>
> I'll answer in the thread. (Oh, you also found #14422.) I think the
> approach above will also fix #14422.
>
>>
>> Do you see any ways forward here?
>>
> .
>
>>
>> Thanks!
>> Richard
>
>
> Maybe I'll give it a try tomorrow.
>
>
> _______________________________________________
> 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/20200831/24b88dc4/attachment.html>