From rae at richarde.dev  Mon Jan  1 14:46:38 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 1 Jan 2024 14:46:38 +0000
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
Message-ID: <010f018cc57db18e-1346a83a-9172-4431-a86b-8471dd0a3d4f-000000@us-east-2.amazonses.com>

Yes that's true of course, but if we had a design that could cover raw strings as well, then we have one fewer quoting construct. I guess the real question is: do we need the ability to toggle between multiline and raw separately? That is, right now we have cooked single-line strings. This proposal is for cooked multiline strings, leaving raw strings for a separate proposal. But maybe we only need cooked single-line strings and raw multiline ones? That would be simpler.

I think wisdom from other languages would be helpful here. I will post on the ticket.

Richard

> On Dec 31, 2023, at 12:04 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> 
>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae at richarde.dev> wrote:
>> 
>> On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes.
> 
> I had a similar thought at first, but I think raw strings can be added independently of this proposal. So long as we are not closing the door to a future addition I think it is fine to take incremental steps. 


From rae at richarde.dev  Tue Jan  2 12:24:13 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 2 Jan 2024 12:24:13 +0000
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
Message-ID: <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>

After some conversation on the ticket, I'd like to vote for acceptance here.

Richard

> On Jan 1, 2024, at 9:46 AM, Richard Eisenberg <rae at richarde.dev> wrote:
> 
> Yes that's true of course, but if we had a design that could cover raw strings as well, then we have one fewer quoting construct. I guess the real question is: do we need the ability to toggle between multiline and raw separately? That is, right now we have cooked single-line strings. This proposal is for cooked multiline strings, leaving raw strings for a separate proposal. But maybe we only need cooked single-line strings and raw multiline ones? That would be simpler.
> 
> I think wisdom from other languages would be helpful here. I will post on the ticket.
> 
> Richard
> 
>> On Dec 31, 2023, at 12:04 PM, Eric Seidel <eric at seidel.io> wrote:
>> 
>> 
>>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae at richarde.dev> wrote:
>>> 
>>> On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes.
>> 
>> I had a similar thought at first, but I think raw strings can be added independently of this proposal. So long as we are not closing the door to a future addition I think it is fine to take incremental steps. 
> 


From rae at richarde.dev  Tue Jan  2 12:55:45 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 2 Jan 2024 12:55:45 +0000
Subject: [ghc-steering-committee] #626: Amendment of Visible Forall in
 Types, recommendation: Accept
In-Reply-To: <CAGwnsnkM7FPRAXeTik5g2Na3s+Dzv2ifAhkzpukydaQ8Hz0NTQ@mail.gmail.com>
References: <CAGwnsnkpCa2NMPBPDd_hEA=vHQLbMzvtr78+EJsYQDa5Qcu+DQ@mail.gmail.com>
 <CAJKmMz9+-xpr-X5V+4A=1Ctuvs9Xd+5oW8UgzRbZ8d=sQqU_tQ@mail.gmail.com>
 <CAGwnsnkM7FPRAXeTik5g2Na3s+Dzv2ifAhkzpukydaQ8Hz0NTQ@mail.gmail.com>
Message-ID: <010f018cca3e8920-cd21c435-0d3e-4c0b-8ba1-e4319539ed5d-000000@us-east-2.amazonses.com>

I support the amendment. I made one small suggestion, but I wish to vote for acceptance regardless of the status of this suggestion.

Richard

> On Dec 22, 2023, at 9:20 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> I realised today that we haven't completed the vote on this. This is really a very simple proposal, let's not spend too long on this. I'll be on holiday for the next two weeks, I'm a bit embarrassed to send this email only now. But please opine soon. I'd like to be able to give an answer soon after I'm back (say on the 12th January)
> 
> Best,
> Arnaud
> 
> On Mon, 11 Dec 2023 at 11:06, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> I recommend acceptance too.  It's all very fine detail.
> 
> The actual diff seems quite large but that's because I encouraged Vlad to take the opportunity to clarity the rather cryptic sentence in the original #218, namely "The syntactic descriptions here applying to expressions apply equally to patterns, though we will continue to discuss only expressions."  Instead it is all spelled out much more explicitly, which is way better.  Indeed spelling it out showed up a dark corner to do with view patterns, hence the icky stuff Arnaud mentions.
> 
> Simon
> 
> 
> On Mon, 11 Dec 2023 at 09:56, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> Dear all,
> 
> Vlad is proposing to amend his own proposal https://github.com/ghc-proposals/ghc-proposals/pull/626 <https://github.com/ghc-proposals/ghc-proposals/pull/626>
> 
> Being an amendment, it's, as always, not as straightforward to consume, but Vlad gives us a good summary of the changes in his pull-request description.
> 
> All in all, it's almost entirely straightforward clarification. There are two items of notice: patterns for visible forall arguments were specified as: only variable or wildcard. The amendment changes it to allow data constructors applied to (0 or more) patterns as well. The amended version is consistent with how patterns for invisible forall arguments are specified. The second, and this one is for Moritz, is a small change in the parsing of view patterns (it does break two packages at least on Hackage, but I actually don't quite understand how the change can affect semantics. It's that tiny. Vlad proposes 3 releases with warning before effecting the change).
> 
> Maybe there's a third item: `p -> q` parses differently depending on whether ViewPattern or RequiredTypeArguments (or both) is turned on. This is kind of icky, I suppose. But in the case where both are on, then ViewPattern wins, so there's no real harm in it.
> 
> Do pay some attention to the new items in the alternatives section.
> 
> Anyway, I recommend we accept.
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240102/b6cb6d71/attachment.html>

From mail at joachim-breitner.de  Wed Jan  3 11:21:19 2024
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 03 Jan 2024 12:21:19 +0100
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
Message-ID: <c9646b15a936214b673e4a7a7f5e6f13946203be.camel@joachim-breitner.de>

Happy new year everyone!

Am Freitag, dem 08.12.2023 um 18:54 +0100 schrieb Joachim Breitner:
> Ballot boxes are upen until Jan 8th, but it is probably better for
> everyone if votes are casted sooner. Maybe we can do it within a week?

5 more days of voting, still waiting for the ballot from Moritz and
Chris.

So far, we have DerivingStrategies, DisambiguateRecordFields, GADTs
with MonoLocalBinds and LambdaCase are definitely in, and TypeData and
BlockArguments are definitely out.

Cheers,
Joachim


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


From simon.peytonjones at gmail.com  Wed Jan  3 12:17:48 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 3 Jan 2024 12:17:48 +0000
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>

I'm content to accept, but only when the specification is made precise.

Simon

On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg <rae at richarde.dev> wrote:

> After some conversation on the ticket, I'd like to vote for acceptance
> here.
>
> Richard
>
> > On Jan 1, 2024, at 9:46 AM, Richard Eisenberg <rae at richarde.dev> wrote:
> >
> > Yes that's true of course, but if we had a design that could cover raw
> strings as well, then we have one fewer quoting construct. I guess the real
> question is: do we need the ability to toggle between multiline and raw
> separately? That is, right now we have cooked single-line strings. This
> proposal is for cooked multiline strings, leaving raw strings for a
> separate proposal. But maybe we only need cooked single-line strings and
> raw multiline ones? That would be simpler.
> >
> > I think wisdom from other languages would be helpful here. I will post
> on the ticket.
> >
> > Richard
> >
> >> On Dec 31, 2023, at 12:04 PM, Eric Seidel <eric at seidel.io> wrote:
> >>
> >>
> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae at richarde.dev> wrote:
> >>>
> >>> On the other hand, I'm a little worried that this doesn't have support
> for raw strings. That is, even with this, there will still be some users
> who reach for quasiquotes for multi-line strings, if those strings contain
> backslashes.
> >>
> >> I had a similar thought at first, but I think raw strings can be added
> independently of this proposal. So long as we are not closing the door to a
> future addition I think it is fine to take incremental steps.
> >
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240103/7e808742/attachment-0001.html>

From rae at richarde.dev  Wed Jan  3 12:43:25 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 3 Jan 2024 12:43:25 +0000
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
 <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
Message-ID: <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>

I agree that some aspects of this proposal are not as precise as I'd like. But actually I think we should accept before these last few details are worked out. Unless I'm mistaken, there's not a worry that the specific choices will change our minds, and the details will have to be resolved in the course of implementation. Ideally, the proposer will come back and update the proposal. However, the proposal is not the long-lasting record of the specification; the user manual is. (By contrast, the proposal is the long-lasting record of the motivation / discussion / alternatives.) So I would insist in the code-review process that the manual is fully precise, and perhaps to insist that the proposal has a note saying it will be made precise in the course of implementation -- but I don't think we need this to happen before acceptance. Sometimes the details are easier to work out during implementation and can be informed by the tiny bit of experience gained writing tests, etc.

Richard

PS: The viewpoint here -- to work out final details late -- is informed by the common practice at Jane Street. We sketch out a broad idea with a bunch of examples, but we write down the final specification only after implementing. This is so much easier, because it makes the specification process iterative with implementation.

> On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> I'm content to accept, but only when the specification is made precise.
> 
> Simon
> 
> On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> After some conversation on the ticket, I'd like to vote for acceptance here.
> 
> Richard
> 
> > On Jan 1, 2024, at 9:46 AM, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> > 
> > Yes that's true of course, but if we had a design that could cover raw strings as well, then we have one fewer quoting construct. I guess the real question is: do we need the ability to toggle between multiline and raw separately? That is, right now we have cooked single-line strings. This proposal is for cooked multiline strings, leaving raw strings for a separate proposal. But maybe we only need cooked single-line strings and raw multiline ones? That would be simpler.
> > 
> > I think wisdom from other languages would be helpful here. I will post on the ticket.
> > 
> > Richard
> > 
> >> On Dec 31, 2023, at 12:04 PM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
> >> 
> >> 
> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> >>> 
> >>> On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes.
> >> 
> >> I had a similar thought at first, but I think raw strings can be added independently of this proposal. So long as we are not closing the door to a future addition I think it is fine to take incremental steps. 
> > 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240103/7ff181c1/attachment.html>

From simon.peytonjones at gmail.com  Wed Jan  3 12:47:15 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 3 Jan 2024 12:47:15 +0000
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
 <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
 <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz9rE-bVou1XUE+5fEF_Cw8EtrbH+8RhstOZcu5OLPUSWA@mail.gmail.com>

But why wait?  There is no implementation-related uncertainty here.  It's
just a question of writing a precise spec.  It's not even difficult to do!

Sometimes making the spec precise throws up unexpected wrinkles.

I'm not against postponing things where the implementation may influence
details of the spec.  But that's not the case here, I think.

Simon

On Wed, 3 Jan 2024 at 12:43, Richard Eisenberg <rae at richarde.dev> wrote:

> I agree that some aspects of this proposal are not as precise as I'd like.
> But actually I think we should accept before these last few details are
> worked out. Unless I'm mistaken, there's not a worry that the specific
> choices will change our minds, and the details will have to be resolved in
> the course of implementation. Ideally, the proposer will come back and
> update the proposal. However, the proposal is not the long-lasting record
> of the specification; the user manual is. (By contrast, the proposal is the
> long-lasting record of the motivation / discussion / alternatives.) So I
> would insist in the code-review process that the manual is fully precise,
> and perhaps to insist that the proposal has a note saying it will be made
> precise in the course of implementation -- but I don't think we need this
> to happen before acceptance. Sometimes the details are easier to work out
> during implementation and can be informed by the tiny bit of experience
> gained writing tests, etc.
>
> Richard
>
> PS: The viewpoint here -- to work out final details late -- is informed by
> the common practice at Jane Street. We sketch out a broad idea with a bunch
> of examples, but we write down the final specification only after
> implementing. This is so much easier, because it makes the specification
> process iterative with implementation.
>
> On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
> I'm content to accept, but only when the specification is made precise.
>
> Simon
>
> On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> After some conversation on the ticket, I'd like to vote for acceptance
>> here.
>>
>> Richard
>>
>> > On Jan 1, 2024, at 9:46 AM, Richard Eisenberg <rae at richarde.dev> wrote:
>> >
>> > Yes that's true of course, but if we had a design that could cover raw
>> strings as well, then we have one fewer quoting construct. I guess the real
>> question is: do we need the ability to toggle between multiline and raw
>> separately? That is, right now we have cooked single-line strings. This
>> proposal is for cooked multiline strings, leaving raw strings for a
>> separate proposal. But maybe we only need cooked single-line strings and
>> raw multiline ones? That would be simpler.
>> >
>> > I think wisdom from other languages would be helpful here. I will post
>> on the ticket.
>> >
>> > Richard
>> >
>> >> On Dec 31, 2023, at 12:04 PM, Eric Seidel <eric at seidel.io> wrote:
>> >>
>> >>
>> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae at richarde.dev>
>> wrote:
>> >>>
>> >>> On the other hand, I'm a little worried that this doesn't have
>> support for raw strings. That is, even with this, there will still be some
>> users who reach for quasiquotes for multi-line strings, if those strings
>> contain backslashes.
>> >>
>> >> I had a similar thought at first, but I think raw strings can be added
>> independently of this proposal. So long as we are not closing the door to a
>> future addition I think it is fine to take incremental steps.
>> >
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240103/e7d84ae8/attachment.html>

From rae at richarde.dev  Wed Jan  3 12:52:47 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 3 Jan 2024 12:52:47 +0000
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <CAJKmMz9rE-bVou1XUE+5fEF_Cw8EtrbH+8RhstOZcu5OLPUSWA@mail.gmail.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
 <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
 <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>
 <CAJKmMz9rE-bVou1XUE+5fEF_Cw8EtrbH+8RhstOZcu5OLPUSWA@mail.gmail.com>
Message-ID: <010f018ccf623071-9dd56897-7356-4ca2-835f-5a4df09f963e-000000@us-east-2.amazonses.com>



> On Jan 3, 2024, at 7:47 AM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> But why wait? 

To reduce the burden of the proposal process. From the point of view of the proposer, putting yet more time into an as-yet-unaccepted proposal is a hoop to jump through, with uncertain outcome.

As we can observe, writing precise specifications is generally not easy. (If it were easy, then we should expect most proposals to come with one. But almost all proposals are insufficiently precise upon inspection.) I'm just trying to nudge us toward making the process easier (for us, too!).

Richard


> There is no implementation-related uncertainty here.  It's just a question of writing a precise spec.  It's not even difficult to do!
> 
> Sometimes making the spec precise throws up unexpected wrinkles.  
> 
> I'm not against postponing things where the implementation may influence details of the spec.  But that's not the case here, I think.
> 
> Simon
> 
> On Wed, 3 Jan 2024 at 12:43, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> I agree that some aspects of this proposal are not as precise as I'd like. But actually I think we should accept before these last few details are worked out. Unless I'm mistaken, there's not a worry that the specific choices will change our minds, and the details will have to be resolved in the course of implementation. Ideally, the proposer will come back and update the proposal. However, the proposal is not the long-lasting record of the specification; the user manual is. (By contrast, the proposal is the long-lasting record of the motivation / discussion / alternatives.) So I would insist in the code-review process that the manual is fully precise, and perhaps to insist that the proposal has a note saying it will be made precise in the course of implementation -- but I don't think we need this to happen before acceptance. Sometimes the details are easier to work out during implementation and can be informed by the tiny bit of experience gained writing tests, etc.
> 
> Richard
> 
> PS: The viewpoint here -- to work out final details late -- is informed by the common practice at Jane Street. We sketch out a broad idea with a bunch of examples, but we write down the final specification only after implementing. This is so much easier, because it makes the specification process iterative with implementation.
> 
>> On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> 
>> I'm content to accept, but only when the specification is made precise.
>> 
>> Simon
>> 
>> On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>> After some conversation on the ticket, I'd like to vote for acceptance here.
>> 
>> Richard
>> 
>> > On Jan 1, 2024, at 9:46 AM, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>> > 
>> > Yes that's true of course, but if we had a design that could cover raw strings as well, then we have one fewer quoting construct. I guess the real question is: do we need the ability to toggle between multiline and raw separately? That is, right now we have cooked single-line strings. This proposal is for cooked multiline strings, leaving raw strings for a separate proposal. But maybe we only need cooked single-line strings and raw multiline ones? That would be simpler.
>> > 
>> > I think wisdom from other languages would be helpful here. I will post on the ticket.
>> > 
>> > Richard
>> > 
>> >> On Dec 31, 2023, at 12:04 PM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
>> >> 
>> >> 
>> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>> >>> 
>> >>> On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes.
>> >> 
>> >> I had a similar thought at first, but I think raw strings can be added independently of this proposal. So long as we are not closing the door to a future addition I think it is fine to take incremental steps. 
>> > 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240103/1f40b5c0/attachment-0001.html>

From simon.peytonjones at gmail.com  Wed Jan  3 12:56:09 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 3 Jan 2024 12:56:09 +0000
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <010f018ccf623071-9dd56897-7356-4ca2-835f-5a4df09f963e-000000@us-east-2.amazonses.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
 <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
 <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>
 <CAJKmMz9rE-bVou1XUE+5fEF_Cw8EtrbH+8RhstOZcu5OLPUSWA@mail.gmail.com>
 <010f018ccf623071-9dd56897-7356-4ca2-835f-5a4df09f963e-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz9jXWzeN6THtD1SbE9wH=aFMD4XPJyLrs_=wANioJku6A@mail.gmail.com>

If there is a consensus to accept, we can say "Accept provided you make the
spec precise, and that process does not throw up any unexpected
surprises".  I agree that requiring a fully-precise spec for a
subsequently-rejected proposal is dispiriting.

But I worry that if we kick the can down the road

   - there is no mechanism to ensure subsequent precision
   - code reviewers have no spec wrt which to review the code

so maybe it never gets done at all.

Simon

On Wed, 3 Jan 2024 at 12:52, Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Jan 3, 2024, at 7:47 AM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
> But why wait?
>
>
> To reduce the burden of the proposal process. From the point of view of
> the proposer, putting yet more time into an as-yet-unaccepted proposal is a
> hoop to jump through, with uncertain outcome.
>
> As we can observe, writing precise specifications is generally not easy.
> (If it were easy, then we should expect most proposals to come with one.
> But almost all proposals are insufficiently precise upon inspection.) I'm
> just trying to nudge us toward making the process easier (for us, too!).
>
> Richard
>
>
> There is no implementation-related uncertainty here.  It's just a question
> of writing a precise spec.  It's not even difficult to do!
>
> Sometimes making the spec precise throws up unexpected wrinkles.
>
> I'm not against postponing things where the implementation may influence
> details of the spec.  But that's not the case here, I think.
>
> Simon
>
> On Wed, 3 Jan 2024 at 12:43, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> I agree that some aspects of this proposal are not as precise as I'd
>> like. But actually I think we should accept before these last few details
>> are worked out. Unless I'm mistaken, there's not a worry that the specific
>> choices will change our minds, and the details will have to be resolved in
>> the course of implementation. Ideally, the proposer will come back and
>> update the proposal. However, the proposal is not the long-lasting record
>> of the specification; the user manual is. (By contrast, the proposal is the
>> long-lasting record of the motivation / discussion / alternatives.) So I
>> would insist in the code-review process that the manual is fully precise,
>> and perhaps to insist that the proposal has a note saying it will be made
>> precise in the course of implementation -- but I don't think we need this
>> to happen before acceptance. Sometimes the details are easier to work out
>> during implementation and can be informed by the tiny bit of experience
>> gained writing tests, etc.
>>
>> Richard
>>
>> PS: The viewpoint here -- to work out final details late -- is informed
>> by the common practice at Jane Street. We sketch out a broad idea with a
>> bunch of examples, but we write down the final specification only after
>> implementing. This is so much easier, because it makes the specification
>> process iterative with implementation.
>>
>> On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>> I'm content to accept, but only when the specification is made precise.
>>
>> Simon
>>
>> On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>>> After some conversation on the ticket, I'd like to vote for acceptance
>>> here.
>>>
>>> Richard
>>>
>>> > On Jan 1, 2024, at 9:46 AM, Richard Eisenberg <rae at richarde.dev>
>>> wrote:
>>> >
>>> > Yes that's true of course, but if we had a design that could cover raw
>>> strings as well, then we have one fewer quoting construct. I guess the real
>>> question is: do we need the ability to toggle between multiline and raw
>>> separately? That is, right now we have cooked single-line strings. This
>>> proposal is for cooked multiline strings, leaving raw strings for a
>>> separate proposal. But maybe we only need cooked single-line strings and
>>> raw multiline ones? That would be simpler.
>>> >
>>> > I think wisdom from other languages would be helpful here. I will post
>>> on the ticket.
>>> >
>>> > Richard
>>> >
>>> >> On Dec 31, 2023, at 12:04 PM, Eric Seidel <eric at seidel.io> wrote:
>>> >>
>>> >>
>>> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae at richarde.dev>
>>> wrote:
>>> >>>
>>> >>> On the other hand, I'm a little worried that this doesn't have
>>> support for raw strings. That is, even with this, there will still be some
>>> users who reach for quasiquotes for multi-line strings, if those strings
>>> contain backslashes.
>>> >>
>>> >> I had a similar thought at first, but I think raw strings can be
>>> added independently of this proposal. So long as we are not closing the
>>> door to a future addition I think it is fine to take incremental steps.
>>> >
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240103/91bd59d5/attachment.html>

From rae at richarde.dev  Wed Jan  3 13:05:27 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 3 Jan 2024 13:05:27 +0000
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <CAJKmMz9jXWzeN6THtD1SbE9wH=aFMD4XPJyLrs_=wANioJku6A@mail.gmail.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
 <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
 <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>
 <CAJKmMz9rE-bVou1XUE+5fEF_Cw8EtrbH+8RhstOZcu5OLPUSWA@mail.gmail.com>
 <010f018ccf623071-9dd56897-7356-4ca2-835f-5a4df09f963e-000000@us-east-2.amazonses.com>
 <CAJKmMz9jXWzeN6THtD1SbE9wH=aFMD4XPJyLrs_=wANioJku6A@mail.gmail.com>
Message-ID: <010f018ccf6dc808-374c3c04-defd-4ca5-b5fe-13db67d8e556-000000@us-east-2.amazonses.com>



> On Jan 3, 2024, at 7:56 AM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> If there is a consensus to accept, we can say "Accept provided you make the spec precise, and that process does not throw up any unexpected surprises".  I agree that requiring a fully-precise spec for a subsequently-rejected proposal is dispiriting.
> 
> But I worry that if we kick the can down the road
> there is no mechanism to ensure subsequent precision
But there is! Code review, for the user manual entry.
> code reviewers have no spec wrt which to review the code
This can be problematic -- but reviewers should then insist that the manual entry is precise so that they can review the code.

> so maybe it never gets done at all.
> 
> Simon
> 
> On Wed, 3 Jan 2024 at 12:52, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> 
> 
>> On Jan 3, 2024, at 7:47 AM, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> 
>> But why wait? 
> 
> To reduce the burden of the proposal process. From the point of view of the proposer, putting yet more time into an as-yet-unaccepted proposal is a hoop to jump through, with uncertain outcome.
> 
> As we can observe, writing precise specifications is generally not easy. (If it were easy, then we should expect most proposals to come with one. But almost all proposals are insufficiently precise upon inspection.) I'm just trying to nudge us toward making the process easier (for us, too!).
> 
> Richard
> 
> 
>> There is no implementation-related uncertainty here.  It's just a question of writing a precise spec.  It's not even difficult to do!
>> 
>> Sometimes making the spec precise throws up unexpected wrinkles.  
>> 
>> I'm not against postponing things where the implementation may influence details of the spec.  But that's not the case here, I think.
>> 
>> Simon
>> 
>> On Wed, 3 Jan 2024 at 12:43, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>> I agree that some aspects of this proposal are not as precise as I'd like. But actually I think we should accept before these last few details are worked out. Unless I'm mistaken, there's not a worry that the specific choices will change our minds, and the details will have to be resolved in the course of implementation. Ideally, the proposer will come back and update the proposal. However, the proposal is not the long-lasting record of the specification; the user manual is. (By contrast, the proposal is the long-lasting record of the motivation / discussion / alternatives.) So I would insist in the code-review process that the manual is fully precise, and perhaps to insist that the proposal has a note saying it will be made precise in the course of implementation -- but I don't think we need this to happen before acceptance. Sometimes the details are easier to work out during implementation and can be informed by the tiny bit of experience gained writing tests, etc.
>> 
>> Richard
>> 
>> PS: The viewpoint here -- to work out final details late -- is informed by the common practice at Jane Street. We sketch out a broad idea with a bunch of examples, but we write down the final specification only after implementing. This is so much easier, because it makes the specification process iterative with implementation.
>> 
>>> On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>> 
>>> I'm content to accept, but only when the specification is made precise.
>>> 
>>> Simon
>>> 
>>> On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>>> After some conversation on the ticket, I'd like to vote for acceptance here.
>>> 
>>> Richard
>>> 
>>> > On Jan 1, 2024, at 9:46 AM, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>>> > 
>>> > Yes that's true of course, but if we had a design that could cover raw strings as well, then we have one fewer quoting construct. I guess the real question is: do we need the ability to toggle between multiline and raw separately? That is, right now we have cooked single-line strings. This proposal is for cooked multiline strings, leaving raw strings for a separate proposal. But maybe we only need cooked single-line strings and raw multiline ones? That would be simpler.
>>> > 
>>> > I think wisdom from other languages would be helpful here. I will post on the ticket.
>>> > 
>>> > Richard
>>> > 
>>> >> On Dec 31, 2023, at 12:04 PM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
>>> >> 
>>> >> 
>>> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>>> >>> 
>>> >>> On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes.
>>> >> 
>>> >> I had a similar thought at first, but I think raw strings can be added independently of this proposal. So long as we are not closing the door to a future addition I think it is fine to take incremental steps. 
>>> > 
>>> 
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240103/be7c6a09/attachment-0001.html>

From simon.peytonjones at gmail.com  Wed Jan  3 13:13:24 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 3 Jan 2024 13:13:24 +0000
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <010f018ccf6dc808-374c3c04-defd-4ca5-b5fe-13db67d8e556-000000@us-east-2.amazonses.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
 <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
 <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>
 <CAJKmMz9rE-bVou1XUE+5fEF_Cw8EtrbH+8RhstOZcu5OLPUSWA@mail.gmail.com>
 <010f018ccf623071-9dd56897-7356-4ca2-835f-5a4df09f963e-000000@us-east-2.amazonses.com>
 <CAJKmMz9jXWzeN6THtD1SbE9wH=aFMD4XPJyLrs_=wANioJku6A@mail.gmail.com>
 <010f018ccf6dc808-374c3c04-defd-4ca5-b5fe-13db67d8e556-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz_GbawR14jEgc5YoMXuNH_FbA5p5ps5ppQwnPAacQ70+A@mail.gmail.com>

>
> But there is! Code review, for the user manual entry.


I just think that often will not happen.

I am also genuinely unclear about what the spec *is*.   I see no downside,
and significant upside, in resolving that now rather than kicking it down
the road.   I have read the proposal.  I have it paged in.  I don't want to
repeat that process in three weeks, or three months, or three years.

If the author wants to write a user manual entry and put that as the
"proposed change spec" that would be fine with me.  I'm not asking for
duplicated effort.

Simon

On Wed, 3 Jan 2024 at 13:05, Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Jan 3, 2024, at 7:56 AM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
> If there is a consensus to accept, we can say "Accept provided you make
> the spec precise, and that process does not throw up any unexpected
> surprises".  I agree that requiring a fully-precise spec for a
> subsequently-rejected proposal is dispiriting.
>
> But I worry that if we kick the can down the road
>
>    - there is no mechanism to ensure subsequent precision
>
> But there is! Code review, for the user manual entry.
>
>
>    - code reviewers have no spec wrt which to review the code
>
> This can be problematic -- but reviewers should then insist that the
> manual entry is precise so that they can review the code.
>
> so maybe it never gets done at all.
>
> Simon
>
> On Wed, 3 Jan 2024 at 12:52, Richard Eisenberg <rae at richarde.dev> wrote:
>
>>
>>
>> On Jan 3, 2024, at 7:47 AM, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>> But why wait?
>>
>>
>> To reduce the burden of the proposal process. From the point of view of
>> the proposer, putting yet more time into an as-yet-unaccepted proposal is a
>> hoop to jump through, with uncertain outcome.
>>
>> As we can observe, writing precise specifications is generally not easy.
>> (If it were easy, then we should expect most proposals to come with one.
>> But almost all proposals are insufficiently precise upon inspection.) I'm
>> just trying to nudge us toward making the process easier (for us, too!).
>>
>> Richard
>>
>>
>> There is no implementation-related uncertainty here.  It's just a
>> question of writing a precise spec.  It's not even difficult to do!
>>
>> Sometimes making the spec precise throws up unexpected wrinkles.
>>
>> I'm not against postponing things where the implementation may influence
>> details of the spec.  But that's not the case here, I think.
>>
>> Simon
>>
>> On Wed, 3 Jan 2024 at 12:43, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>>> I agree that some aspects of this proposal are not as precise as I'd
>>> like. But actually I think we should accept before these last few details
>>> are worked out. Unless I'm mistaken, there's not a worry that the specific
>>> choices will change our minds, and the details will have to be resolved in
>>> the course of implementation. Ideally, the proposer will come back and
>>> update the proposal. However, the proposal is not the long-lasting record
>>> of the specification; the user manual is. (By contrast, the proposal is the
>>> long-lasting record of the motivation / discussion / alternatives.) So I
>>> would insist in the code-review process that the manual is fully precise,
>>> and perhaps to insist that the proposal has a note saying it will be made
>>> precise in the course of implementation -- but I don't think we need this
>>> to happen before acceptance. Sometimes the details are easier to work out
>>> during implementation and can be informed by the tiny bit of experience
>>> gained writing tests, etc.
>>>
>>> Richard
>>>
>>> PS: The viewpoint here -- to work out final details late -- is informed
>>> by the common practice at Jane Street. We sketch out a broad idea with a
>>> bunch of examples, but we write down the final specification only after
>>> implementing. This is so much easier, because it makes the specification
>>> process iterative with implementation.
>>>
>>> On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>> I'm content to accept, but only when the specification is made precise.
>>>
>>> Simon
>>>
>>> On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg <rae at richarde.dev> wrote:
>>>
>>>> After some conversation on the ticket, I'd like to vote for acceptance
>>>> here.
>>>>
>>>> Richard
>>>>
>>>> > On Jan 1, 2024, at 9:46 AM, Richard Eisenberg <rae at richarde.dev>
>>>> wrote:
>>>> >
>>>> > Yes that's true of course, but if we had a design that could cover
>>>> raw strings as well, then we have one fewer quoting construct. I guess the
>>>> real question is: do we need the ability to toggle between multiline and
>>>> raw separately? That is, right now we have cooked single-line strings. This
>>>> proposal is for cooked multiline strings, leaving raw strings for a
>>>> separate proposal. But maybe we only need cooked single-line strings and
>>>> raw multiline ones? That would be simpler.
>>>> >
>>>> > I think wisdom from other languages would be helpful here. I will
>>>> post on the ticket.
>>>> >
>>>> > Richard
>>>> >
>>>> >> On Dec 31, 2023, at 12:04 PM, Eric Seidel <eric at seidel.io> wrote:
>>>> >>
>>>> >>
>>>> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae at richarde.dev>
>>>> wrote:
>>>> >>>
>>>> >>> On the other hand, I'm a little worried that this doesn't have
>>>> support for raw strings. That is, even with this, there will still be some
>>>> users who reach for quasiquotes for multi-line strings, if those strings
>>>> contain backslashes.
>>>> >>
>>>> >> I had a similar thought at first, but I think raw strings can be
>>>> added independently of this proposal. So long as we are not closing the
>>>> door to a future addition I think it is fine to take incremental steps.
>>>> >
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240103/e96153f0/attachment.html>

From iavor.diatchki at gmail.com  Wed Jan  3 16:48:26 2024
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 3 Jan 2024 08:48:26 -0800
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <c9646b15a936214b673e4a7a7f5e6f13946203be.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
 <c9646b15a936214b673e4a7a7f5e6f13946203be.camel@joachim-breitner.de>
Message-ID: <CAGK9nuopoH6sG2wwUf6baT1Cosiwize88OtDf3b+ACdR3QAAmw@mail.gmail.com>

Greetings from an old member!

I am curious why folks are voting against BlockArguments?   These days it
and ImportQualifiedPost are the two extensions I turn on in pretty much any
new project.

Is the thinking that it it will be removed in the future? That would be
very unfortunate, as I use it a lot, and the change would affect a lot of
code.  If not, are folks concerned about some sort of error it might cause?

I see zero benefit in having to write BlockArguments in the extension field
of my Cabal file, but it's also not that onerous, so not a big deal, just
curious.

Happy new year!
Iavor


On Wed, Jan 3, 2024, 03:21 Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Happy new year everyone!
>
> Am Freitag, dem 08.12.2023 um 18:54 +0100 schrieb Joachim Breitner:
> > Ballot boxes are upen until Jan 8th, but it is probably better for
> > everyone if votes are casted sooner. Maybe we can do it within a week?
>
> 5 more days of voting, still waiting for the ballot from Moritz and
> Chris.
>
> So far, we have DerivingStrategies, DisambiguateRecordFields, GADTs
> with MonoLocalBinds and LambdaCase are definitely in, and TypeData and
> BlockArguments are definitely out.
>
> Cheers,
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240103/f0af862d/attachment.html>

From simon.peytonjones at gmail.com  Thu Jan  4 09:19:24 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 4 Jan 2024 09:19:24 +0000
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <CAGK9nuopoH6sG2wwUf6baT1Cosiwize88OtDf3b+ACdR3QAAmw@mail.gmail.com>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
 <c9646b15a936214b673e4a7a7f5e6f13946203be.camel@joachim-breitner.de>
 <CAGK9nuopoH6sG2wwUf6baT1Cosiwize88OtDf3b+ACdR3QAAmw@mail.gmail.com>
Message-ID: <CAJKmMz_c3S_rg6UMqmQ-utc6KgTjmOn03AwqO+e+hX2GFwytOQ@mail.gmail.com>

>
> I am curious why folks are voting against BlockArguments?   These days it
> and ImportQualifiedPost are the two extensions I turn on in pretty much any
> new project.


I'm not voting against.... I'm just not voting *for*!  I find that
f x do { blah }
is hard to parse.  You may say that the same is true of record update:
g x y { f=3 }
which was a bad mistake IMHO. But we are stuck with that one, and we don't
have to add new ones.

It's just a matter of taste, I know, and I have no complaint about you
using BlockArguments.  But I didn't want to actively vote *for* adding it
to GHC2024.

One thing that would change my mind is if 90%+ of the Haskell community
always switched it in, as you do.  But the poll only showed 43%;
substantial but not overwhelming.

It is hardly a huge issue, but you asked, so I felt you deserved an
explanation.

Simon

On Wed, 3 Jan 2024 at 16:48, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Greetings from an old member!
>
> I am curious why folks are voting against BlockArguments?   These days it
> and ImportQualifiedPost are the two extensions I turn on in pretty much any
> new project.
>
> Is the thinking that it it will be removed in the future? That would be
> very unfortunate, as I use it a lot, and the change would affect a lot of
> code.  If not, are folks concerned about some sort of error it might cause?
>
> I see zero benefit in having to write BlockArguments in the extension
> field of my Cabal file, but it's also not that onerous, so not a big deal,
> just curious.
>
> Happy new year!
> Iavor
>
>
> On Wed, Jan 3, 2024, 03:21 Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Happy new year everyone!
>>
>> Am Freitag, dem 08.12.2023 um 18:54 +0100 schrieb Joachim Breitner:
>> > Ballot boxes are upen until Jan 8th, but it is probably better for
>> > everyone if votes are casted sooner. Maybe we can do it within a week?
>>
>> 5 more days of voting, still waiting for the ballot from Moritz and
>> Chris.
>>
>> So far, we have DerivingStrategies, DisambiguateRecordFields, GADTs
>> with MonoLocalBinds and LambdaCase are definitely in, and TypeData and
>> BlockArguments are definitely out.
>>
>> Cheers,
>> Joachim
>>
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240104/d2150353/attachment-0001.html>

From moritz.angermann at gmail.com  Thu Jan  4 10:53:13 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 4 Jan 2024 06:53:13 -0400
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <CAJKmMz_c3S_rg6UMqmQ-utc6KgTjmOn03AwqO+e+hX2GFwytOQ@mail.gmail.com>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
 <c9646b15a936214b673e4a7a7f5e6f13946203be.camel@joachim-breitner.de>
 <CAGK9nuopoH6sG2wwUf6baT1Cosiwize88OtDf3b+ACdR3QAAmw@mail.gmail.com>
 <CAJKmMz_c3S_rg6UMqmQ-utc6KgTjmOn03AwqO+e+hX2GFwytOQ@mail.gmail.com>
Message-ID: <CAKfdd-z5vWmb2CqBhJ-9_=byevYeaLqYPzKmLQt4SR1XBpUgZg@mail.gmail.com>

* [ ] DataKinds
* [ ] DefaultSignatures
* [x] DerivingStrategies
* [x] DisambiguateRecordFields
* [x] ExplicitNamespaces
* [x] GADTs with MonoLocalBinds
* [ ] GADTs without MonoLocalBinds
* [x] LambdaCase
* [ ] RoleAnnotations
* [ ] TypeData
* [ ] TypeFamilies
* [ ] BlockArguments


On Thu, 4 Jan 2024 at 5:19 AM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I am curious why folks are voting against BlockArguments?   These days it
>> and ImportQualifiedPost are the two extensions I turn on in pretty much any
>> new project.
>
>
> I'm not voting against.... I'm just not voting *for*!  I find that
> f x do { blah }
> is hard to parse.  You may say that the same is true of record update:
> g x y { f=3 }
> which was a bad mistake IMHO. But we are stuck with that one, and we don't
> have to add new ones.
>
> It's just a matter of taste, I know, and I have no complaint about you
> using BlockArguments.  But I didn't want to actively vote *for* adding it
> to GHC2024.
>
> One thing that would change my mind is if 90%+ of the Haskell community
> always switched it in, as you do.  But the poll only showed 43%;
> substantial but not overwhelming.
>
> It is hardly a huge issue, but you asked, so I felt you deserved an
> explanation.
>
> Simon
>
> On Wed, 3 Jan 2024 at 16:48, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>> Greetings from an old member!
>>
>> I am curious why folks are voting against BlockArguments?   These days it
>> and ImportQualifiedPost are the two extensions I turn on in pretty much any
>> new project.
>>
>> Is the thinking that it it will be removed in the future? That would be
>> very unfortunate, as I use it a lot, and the change would affect a lot of
>> code.  If not, are folks concerned about some sort of error it might cause?
>>
>> I see zero benefit in having to write BlockArguments in the extension
>> field of my Cabal file, but it's also not that onerous, so not a big deal,
>> just curious.
>>
>> Happy new year!
>> Iavor
>>
>>
>> On Wed, Jan 3, 2024, 03:21 Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>>> Happy new year everyone!
>>>
>>> Am Freitag, dem 08.12.2023 um 18:54 +0100 schrieb Joachim Breitner:
>>> > Ballot boxes are upen until Jan 8th, but it is probably better for
>>> > everyone if votes are casted sooner. Maybe we can do it within a week?
>>>
>>> 5 more days of voting, still waiting for the ballot from Moritz and
>>> Chris.
>>>
>>> So far, we have DerivingStrategies, DisambiguateRecordFields, GADTs
>>> with MonoLocalBinds and LambdaCase are definitely in, and TypeData and
>>> BlockArguments are definitely out.
>>>
>>> Cheers,
>>> Joachim
>>>
>>>
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240104/c9ea0ad4/attachment.html>

From chris at chrisdornan.com  Fri Jan  5 10:15:44 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 5 Jan 2024 10:15:44 +0000
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
Message-ID: <3B4083BA-48CD-4AA9-8F3C-3623F1FDDD91@chrisdornan.com>

Here is my vote:

* [x] DataKinds
* [ ] DefaultSignatures
* [x] DerivingStrategies
* [x] DisambiguateRecordFields
* [x] ExplicitNamespaces
* [x] GADTs with MonoLocalBinds
* [ ] GADTs without MonoLocalBinds
* [x] LambdaCase
* [x] RoleAnnotations
* [ ] TypeData
* [ ] TypeFamilies
* [ ] BlockArguments

Rationale: I am conservative when it comes to these things and worry about rolling out too much too quickly on our shared understanding of Haskell. This set strikes the right balance for me.

Chris

From chris at chrisdornan.com  Fri Jan  5 10:15:44 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 5 Jan 2024 10:15:44 +0000
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
Message-ID: <3B4083BA-48CD-4AA9-8F3C-3623F1FDDD91@chrisdornan.com>

Here is my vote:

* [x] DataKinds
* [ ] DefaultSignatures
* [x] DerivingStrategies
* [x] DisambiguateRecordFields
* [x] ExplicitNamespaces
* [x] GADTs with MonoLocalBinds
* [ ] GADTs without MonoLocalBinds
* [x] LambdaCase
* [x] RoleAnnotations
* [ ] TypeData
* [ ] TypeFamilies
* [ ] BlockArguments

Rationale: I am conservative when it comes to these things and worry about rolling out too much too quickly on our shared understanding of Haskell. This set strikes the right balance for me.

Chris

From mail at joachim-breitner.de  Fri Jan  5 11:00:56 2024
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 05 Jan 2024 12:00:56 +0100
Subject: [ghc-steering-committee] GHC2024 tally
Message-ID: <a5a5bd186de2d25a19d67d726840dc74dbc106b3.camel@joachim-breitner.de>

Dear committee,


with all votes in (thanks!), the following extensions made quorum to
form GHC2024:

    DataKinds
    DerivingStrategies
    DisambiguateRecordFields
    ExplicitNamespaces
    GADTs (and the implied MonoLocalBinds)
    LambdaCase
    RoleAnnotations

See the full tally in the proposal:
https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst#3tally

Any final thoughts?

Should we hold off accepting that in light of #628 (I don’t hope so).

Cheers,
Joachim



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


From adam at well-typed.com  Fri Jan  5 11:38:47 2024
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 5 Jan 2024 11:38:47 +0000
Subject: [ghc-steering-committee] GHC2024 tally
In-Reply-To: <a5a5bd186de2d25a19d67d726840dc74dbc106b3.camel@joachim-breitner.de>
References: <a5a5bd186de2d25a19d67d726840dc74dbc106b3.camel@joachim-breitner.de>
Message-ID: <87f66839-d425-4178-80e7-d15c6555314f@well-typed.com>

Thanks Joachim! I'm (unsurprisingly) happy with the result, and I agree 
that we should complete the process and go ahead with defining GHC2024 
in time for 9.10, even if #628 leads to a bigger shake-up in the future.

Cheers,

Adam



On 05/01/2024 11:00, Joachim Breitner wrote:
> Dear committee,
> 
> 
> with all votes in (thanks!), the following extensions made quorum to
> form GHC2024:
> 
>      DataKinds
>      DerivingStrategies
>      DisambiguateRecordFields
>      ExplicitNamespaces
>      GADTs (and the implied MonoLocalBinds)
>      LambdaCase
>      RoleAnnotations
> 
> See the full tally in the proposal:
> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst#3tally
> 
> Any final thoughts?
> 
> Should we hold off accepting that in light of #628 (I don’t hope so).
> 
> Cheers,
> Joachim

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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From rae at richarde.dev  Sat Jan  6 04:45:19 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Sat, 6 Jan 2024 04:45:19 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
	recommendation: accept
Message-ID: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>

Hi all,

I've reviewed Arnaud's https://github.com/ghc-proposals/ghc-proposals/pull/624 <https://github.com/ghc-proposals/ghc-proposals/pull/624> and wish to recommend acceptance.

The proposal is an amendment to the proposal for linear types, adding support for linear let bindings.

Today, if you have

f :: T %1-> T
f t = let t2 = t in t2

you'll get an error because t2 is not linear. The only way to bind a linear variable is via a `case`, never a `let` or `where`. This is annoying. With this proposal, the little program above is accepted, with an inferred linearity restriction on t2. Users can also annotated their lets like `let %1 x = ... in ...`. Bindings in `where` clauses can also be inferred or annotated as linear.

There is a downside, of course: linear bindings have various restrictions, chiefly that they must be strict bindings (because projections are hard with linear types) and that bindings cannot be generalized. I'm a little unsure that the choices in the proposal (particularly around generalization) are the best for users, but I think the best way to learn is to experiment. In my understanding, the community knows that -XLinearTypes is subject to revision, and so I think we should just blast ahead, revising if and when necessary.

Please share your thoughts!

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240106/7c6c4fd7/attachment.html>

From mail at joachim-breitner.de  Sat Jan  6 14:46:16 2024
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 06 Jan 2024 15:46:16 +0100
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
Message-ID: <4b0baa1f55e7b27c05cead2faef4528564a737b3.camel@joachim-breitner.de>

Am Samstag, dem 06.01.2024 um 04:45 +0000 schrieb Richard Eisenberg:
> think we should just blast ahead, revising if and when necessary.

SGTM

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


From simon.peytonjones at gmail.com  Mon Jan  8 09:07:32 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 8 Jan 2024 09:07:32 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>

I support acceptance.  Let's land this soon.

Simon

On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev> wrote:

> Hi all,
>
> I've reviewed Arnaud's
> https://github.com/ghc-proposals/ghc-proposals/pull/624 and wish to
> recommend acceptance.
>
> The proposal is an amendment to the proposal for linear types, adding
> support for linear let bindings.
>
> Today, if you have
>
> f :: T %1-> T
> f t = let t2 = t in t2
>
> you'll get an error because t2 is not linear. The only way to bind a
> linear variable is via a `case`, never a `let` or `where`. This is
> annoying. With this proposal, the little program above is accepted, with an
> inferred linearity restriction on t2. Users can also annotated their lets
> like `let %1 x = ... in ...`. Bindings in `where` clauses can also be
> inferred or annotated as linear.
>
> There is a downside, of course: linear bindings have various restrictions,
> chiefly that they must be strict bindings (because projections are hard
> with linear types) and that bindings cannot be generalized. I'm a little
> unsure that the choices in the proposal (particularly around
> generalization) are the best for users, but I think the best way to learn
> is to experiment. In my understanding, the community knows that
> -XLinearTypes is subject to revision, and so I think we should just blast
> ahead, revising if and when necessary.
>
> Please share your thoughts!
>
> Thanks,
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240108/26323d56/attachment.html>

From simon.peytonjones at gmail.com  Mon Jan  8 16:03:31 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 8 Jan 2024 16:03:31 +0000
Subject: [ghc-steering-committee] Please review #625: Stability Goals,
 Shepherd: Moritz
In-Reply-To: <1ef858b4eb70f0535f2802cc19e8d772e655511a.camel@joachim-breitner.de>
References: <1ef858b4eb70f0535f2802cc19e8d772e655511a.camel@joachim-breitner.de>
Message-ID: <CAJKmMz8Ae3aY2CfThUbSTzHYnncupx56bsUHF4Qp8EQy-haoOg@mail.gmail.com>

Moritz, Happy New Year!

Could you make a recommendation please?

Thanks

Simon

On Mon, 18 Dec 2023 at 16:02, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> Simon wrote up the new Stability policy:
> https://github.com/ghc-proposals/ghc-proposals/pull/625
>
> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles
>
> Given that Moritz has stability very high on his agenda, I suggest he
> shepherds this through the process.
>
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
>
> Cheers,
> Joachim
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240108/76e88cbe/attachment.html>

From arnaud.spiwack at tweag.io  Mon Jan  8 16:53:57 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 8 Jan 2024 17:53:57 +0100
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <CAJKmMz_c3S_rg6UMqmQ-utc6KgTjmOn03AwqO+e+hX2GFwytOQ@mail.gmail.com>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
 <c9646b15a936214b673e4a7a7f5e6f13946203be.camel@joachim-breitner.de>
 <CAGK9nuopoH6sG2wwUf6baT1Cosiwize88OtDf3b+ACdR3QAAmw@mail.gmail.com>
 <CAJKmMz_c3S_rg6UMqmQ-utc6KgTjmOn03AwqO+e+hX2GFwytOQ@mail.gmail.com>
Message-ID: <CAGwnsnm+vKd0dQQr34m1Ma-XWoj81hqn29M6Guu-LCQ7DNhpfA@mail.gmail.com>

> One thing that would change my mind is if 90%+ of the Haskell community
> always switched it in, as you do.  But the poll only showed 43%;
> substantial but not overwhelming.
>

Honestly, if we trust that ~45% of active Haskell programmers use
BlockArgument, then I'd say it's a pretty convincing argument to include
it. I'm absolutely not intent on using it (in fact, the mere existence of
BlockArgument is a little baffling to me), but turning it on doesn't force
me to use it. So if 50% of Haskellers care enough to actively turn on the
extension, I think we can consider it a pretty compelling reason to have
BlockArgument by default.

/Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240108/dd1d4230/attachment.html>

From arnaud.spiwack at tweag.io  Mon Jan  8 17:02:34 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 8 Jan 2024 18:02:34 +0100
Subject: [ghc-steering-committee] GHC2024 tally
In-Reply-To: <87f66839-d425-4178-80e7-d15c6555314f@well-typed.com>
References: <a5a5bd186de2d25a19d67d726840dc74dbc106b3.camel@joachim-breitner.de>
 <87f66839-d425-4178-80e7-d15c6555314f@well-typed.com>
Message-ID: <CAGwnsnkPNMGCgX0bJ2hhBUUPtUM7YwtcpQiUO-6gaQ5_MLuqrQ@mail.gmail.com>

This is such a short list :-/ . At this rate, it'll take about 30 years to
absorb the current mass of extensions GHC. We absolutely need to be more
aggressive there. Either in GHC20XX, or in deprecating extensions. But
we're getting nowhere near getting this hydra under control.

On Fri, 5 Jan 2024 at 12:39, Adam Gundry <adam at well-typed.com> wrote:

> Thanks Joachim! I'm (unsurprisingly) happy with the result, and I agree
> that we should complete the process and go ahead with defining GHC2024
> in time for 9.10, even if #628 leads to a bigger shake-up in the future.
>
> Cheers,
>
> Adam
>
>
>
> On 05/01/2024 11:00, Joachim Breitner wrote:
> > Dear committee,
> >
> >
> > with all votes in (thanks!), the following extensions made quorum to
> > form GHC2024:
> >
> >      DataKinds
> >      DerivingStrategies
> >      DisambiguateRecordFields
> >      ExplicitNamespaces
> >      GADTs (and the implied MonoLocalBinds)
> >      LambdaCase
> >      RoleAnnotations
> >
> > See the full tally in the proposal:
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst#3tally
> >
> > Any final thoughts?
> >
> > Should we hold off accepting that in light of #628 (I don’t hope so).
> >
> > Cheers,
> > Joachim
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240108/bb447cd2/attachment.html>

From vlad.z.4096 at gmail.com  Mon Jan  8 17:29:05 2024
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Mon, 8 Jan 2024 18:29:05 +0100
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <CAGwnsnm+vKd0dQQr34m1Ma-XWoj81hqn29M6Guu-LCQ7DNhpfA@mail.gmail.com>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
 <c9646b15a936214b673e4a7a7f5e6f13946203be.camel@joachim-breitner.de>
 <CAGK9nuopoH6sG2wwUf6baT1Cosiwize88OtDf3b+ACdR3QAAmw@mail.gmail.com>
 <CAJKmMz_c3S_rg6UMqmQ-utc6KgTjmOn03AwqO+e+hX2GFwytOQ@mail.gmail.com>
 <CAGwnsnm+vKd0dQQr34m1Ma-XWoj81hqn29M6Guu-LCQ7DNhpfA@mail.gmail.com>
Message-ID: <CAHZ0NLpq-O2xpJo7KBoeD2v4FSJWRj+oHxb4OFgB5k070i4BuA@mail.gmail.com>

I'm a huge fan of BlockArguments in limited doses. There are some good
idioms with them, e.g.

1. bracket createResource destroyResource \resource -> do
      ...

2. when cond do
      ...

3. for elems \elem -> do
      ...

Adding the `$` to those examples is just syntactic noise. It's quite clear
what's going on without it.

I know some people found ways to abuse BlockArguments, e.g. by prefixing
each function argument with a `do`, and I'm not a fan of that. But with
some sense of taste it's possible to put BlockArguments to good use.

Vlad

On Mon, Jan 8, 2024 at 5:54 PM Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

>
> One thing that would change my mind is if 90%+ of the Haskell community
>> always switched it in, as you do.  But the poll only showed 43%;
>> substantial but not overwhelming.
>>
>
> Honestly, if we trust that ~45% of active Haskell programmers use
> BlockArgument, then I'd say it's a pretty convincing argument to include
> it. I'm absolutely not intent on using it (in fact, the mere existence of
> BlockArgument is a little baffling to me), but turning it on doesn't force
> me to use it. So if 50% of Haskellers care enough to actively turn on the
> extension, I think we can consider it a pretty compelling reason to have
> BlockArgument by default.
>
> /Arnaud
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240108/c2b8ca25/attachment-0001.html>

From arnaud.spiwack at tweag.io  Tue Jan  9 15:43:42 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 9 Jan 2024 16:43:42 +0100
Subject: [ghc-steering-committee] #626: Amendment of Visible Forall in
 Types, recommendation: Accept
In-Reply-To: <010f018cca3e8920-cd21c435-0d3e-4c0b-8ba1-e4319539ed5d-000000@us-east-2.amazonses.com>
References: <CAGwnsnkpCa2NMPBPDd_hEA=vHQLbMzvtr78+EJsYQDa5Qcu+DQ@mail.gmail.com>
 <CAJKmMz9+-xpr-X5V+4A=1Ctuvs9Xd+5oW8UgzRbZ8d=sQqU_tQ@mail.gmail.com>
 <CAGwnsnkM7FPRAXeTik5g2Na3s+Dzv2ifAhkzpukydaQ8Hz0NTQ@mail.gmail.com>
 <010f018cca3e8920-cd21c435-0d3e-4c0b-8ba1-e4319539ed5d-000000@us-east-2.amazonses.com>
Message-ID: <CAGwnsnmgqk8qzueATWiWg4_81Av2c1S+tyRaECxn5iWFZV674Q@mail.gmail.com>

Any other thoughts? If not, I'll consider this proposal accepted at the end
of this week.

On Tue, 2 Jan 2024 at 13:55, Richard Eisenberg <rae at richarde.dev> wrote:

> I support the amendment. I made one small suggestion, but I wish to vote
> for acceptance regardless of the status of this suggestion.
>
> Richard
>
> On Dec 22, 2023, at 9:20 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
> I realised today that we haven't completed the vote on this. This is
> really a very simple proposal, let's not spend too long on this. I'll be on
> holiday for the next two weeks, I'm a bit embarrassed to send this email
> only now. But please opine soon. I'd like to be able to give an answer soon
> after I'm back (say on the 12th January)
>
> Best,
> Arnaud
>
> On Mon, 11 Dec 2023 at 11:06, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I recommend acceptance too.  It's all very fine detail.
>>
>> The actual diff seems quite large but that's because I encouraged Vlad to
>> take the opportunity to clarity the rather cryptic sentence in the original
>> #218, namely "The syntactic descriptions here applying to expressions apply
>> equally to patterns, though we will continue to discuss only expressions."
>> Instead it is all spelled out much more explicitly, which is way better.
>> Indeed spelling it out showed up a dark corner to do with view patterns,
>> hence the icky stuff Arnaud mentions.
>>
>> Simon
>>
>>    -
>>
>>
>> On Mon, 11 Dec 2023 at 09:56, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> Dear all,
>>>
>>> Vlad is proposing to amend his own proposal
>>> https://github.com/ghc-proposals/ghc-proposals/pull/626
>>>
>>> Being an amendment, it's, as always, not as straightforward to consume,
>>> but Vlad gives us a good summary of the changes in his pull-request
>>> description.
>>>
>>> All in all, it's almost entirely straightforward clarification. There
>>> are two items of notice: patterns for visible forall arguments were
>>> specified as: only variable or wildcard. The amendment changes it to allow
>>> data constructors applied to (0 or more) patterns as well. The amended
>>> version is consistent with how patterns for invisible forall arguments are
>>> specified. The second, and this one is for Moritz, is a small change in the
>>> parsing of view patterns (it does break two packages at least on Hackage,
>>> but I actually don't quite understand how the change can affect semantics.
>>> It's that tiny. Vlad proposes 3 releases with warning before effecting the
>>> change).
>>>
>>> Maybe there's a third item: `p -> q` parses differently depending on
>>> whether ViewPattern or RequiredTypeArguments (or both) is turned on. This
>>> is kind of icky, I suppose. But in the case where both are on, then
>>> ViewPattern wins, so there's no real harm in it.
>>>
>>> Do pay some attention to the new items in the alternatives section.
>>>
>>> Anyway, I recommend we accept.
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240109/f19bc375/attachment.html>

From mail at joachim-breitner.de  Tue Jan  9 20:34:16 2024
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 09 Jan 2024 21:34:16 +0100
Subject: [ghc-steering-committee] GHC2024 tally
In-Reply-To: <87f66839-d425-4178-80e7-d15c6555314f@well-typed.com>
References: <a5a5bd186de2d25a19d67d726840dc74dbc106b3.camel@joachim-breitner.de>
 <87f66839-d425-4178-80e7-d15c6555314f@well-typed.com>
Message-ID: <6a9e7e1e4fc00b138aa4e6b2e8c4241b78912caf.camel@joachim-breitner.de>

Hi,

accepted and merged, and there is a MR against GHC:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11882

Cheers,
Joachim

Am Freitag, dem 05.01.2024 um 11:38 +0000 schrieb Adam Gundry:
> Thanks Joachim! I'm (unsurprisingly) happy with the result, and I agree 
> that we should complete the process and go ahead with defining GHC2024 
> in time for 9.10, even if #628 leads to a bigger shake-up in the future.
> 
> Cheers,
> 
> Adam
> 
> 
> 
> On 05/01/2024 11:00, Joachim Breitner wrote:
> > Dear committee,
> > 
> > 
> > with all votes in (thanks!), the following extensions made quorum to
> > form GHC2024:
> > 
> >      DataKinds
> >      DerivingStrategies
> >      DisambiguateRecordFields
> >      ExplicitNamespaces
> >      GADTs (and the implied MonoLocalBinds)
> >      LambdaCase
> >      RoleAnnotations
> > 
> > See the full tally in the proposal:
> > https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst#3tally
> > 
> > Any final thoughts?
> > 
> > Should we hold off accepting that in light of #628 (I don’t hope so).
> > 
> > Cheers,
> > Joachim
> 

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


From arnaud.spiwack at tweag.io  Wed Jan 10 14:14:58 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Wed, 10 Jan 2024 15:14:58 +0100
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <CAJKmMz_GbawR14jEgc5YoMXuNH_FbA5p5ps5ppQwnPAacQ70+A@mail.gmail.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
 <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
 <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>
 <CAJKmMz9rE-bVou1XUE+5fEF_Cw8EtrbH+8RhstOZcu5OLPUSWA@mail.gmail.com>
 <010f018ccf623071-9dd56897-7356-4ca2-835f-5a4df09f963e-000000@us-east-2.amazonses.com>
 <CAJKmMz9jXWzeN6THtD1SbE9wH=aFMD4XPJyLrs_=wANioJku6A@mail.gmail.com>
 <010f018ccf6dc808-374c3c04-defd-4ca5-b5fe-13db67d8e556-000000@us-east-2.amazonses.com>
 <CAJKmMz_GbawR14jEgc5YoMXuNH_FbA5p5ps5ppQwnPAacQ70+A@mail.gmail.com>
Message-ID: <CAGwnsnm0-UiyNmhJx-eaO973JUv5=tWw3cum=e_S943AZfBy1Q@mail.gmail.com>

In favour.

Turning all the tabs among the leading whitespaces (rather than, say, just
the tabs that get “broken” by leading space removal) is rather
idiosyncratic. But if you absolutely need tabs at the beginning of your
string you can `\t` (in fact, if it's important, you probably want to do so
as it communicates intent much more explicitly). Apart from that, I feel
that the proposal generally matches intuition (there's no perfect way to do
multiline string anyway).

For the delimiter, there are several alternatives proposed (including
having all """+ as delimiters, which would allow fewer escape in case you
need """ in your string, this one has the benefit of being backward
compatible with the current """). Ocaml has a nice alternative: {id|…|id}
(the identifier can be empty). Any character besides |id} continue the
string (Ocaml doesn't do any sort of leading space trimming with this sort
of strings, but it's besides the point). Should we add this in the
alternatives section?

On Wed, 3 Jan 2024 at 14:13, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> But there is! Code review, for the user manual entry.
>
>
> I just think that often will not happen.
>
> I am also genuinely unclear about what the spec *is*.   I see no downside,
> and significant upside, in resolving that now rather than kicking it down
> the road.   I have read the proposal.  I have it paged in.  I don't want to
> repeat that process in three weeks, or three months, or three years.
>
> If the author wants to write a user manual entry and put that as the
> "proposed change spec" that would be fine with me.  I'm not asking for
> duplicated effort.
>
> Simon
>
> On Wed, 3 Jan 2024 at 13:05, Richard Eisenberg <rae at richarde.dev> wrote:
>
>>
>>
>> On Jan 3, 2024, at 7:56 AM, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>> If there is a consensus to accept, we can say "Accept provided you make
>> the spec precise, and that process does not throw up any unexpected
>> surprises".  I agree that requiring a fully-precise spec for a
>> subsequently-rejected proposal is dispiriting.
>>
>> But I worry that if we kick the can down the road
>>
>>    - there is no mechanism to ensure subsequent precision
>>
>> But there is! Code review, for the user manual entry.
>>
>>
>>    - code reviewers have no spec wrt which to review the code
>>
>> This can be problematic -- but reviewers should then insist that the
>> manual entry is precise so that they can review the code.
>>
>> so maybe it never gets done at all.
>>
>> Simon
>>
>> On Wed, 3 Jan 2024 at 12:52, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>>>
>>>
>>> On Jan 3, 2024, at 7:47 AM, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>> But why wait?
>>>
>>>
>>> To reduce the burden of the proposal process. From the point of view of
>>> the proposer, putting yet more time into an as-yet-unaccepted proposal is a
>>> hoop to jump through, with uncertain outcome.
>>>
>>> As we can observe, writing precise specifications is generally not easy.
>>> (If it were easy, then we should expect most proposals to come with one.
>>> But almost all proposals are insufficiently precise upon inspection.) I'm
>>> just trying to nudge us toward making the process easier (for us, too!).
>>>
>>> Richard
>>>
>>>
>>> There is no implementation-related uncertainty here.  It's just a
>>> question of writing a precise spec.  It's not even difficult to do!
>>>
>>> Sometimes making the spec precise throws up unexpected wrinkles.
>>>
>>> I'm not against postponing things where the implementation may influence
>>> details of the spec.  But that's not the case here, I think.
>>>
>>> Simon
>>>
>>> On Wed, 3 Jan 2024 at 12:43, Richard Eisenberg <rae at richarde.dev> wrote:
>>>
>>>> I agree that some aspects of this proposal are not as precise as I'd
>>>> like. But actually I think we should accept before these last few details
>>>> are worked out. Unless I'm mistaken, there's not a worry that the specific
>>>> choices will change our minds, and the details will have to be resolved in
>>>> the course of implementation. Ideally, the proposer will come back and
>>>> update the proposal. However, the proposal is not the long-lasting record
>>>> of the specification; the user manual is. (By contrast, the proposal is the
>>>> long-lasting record of the motivation / discussion / alternatives.) So I
>>>> would insist in the code-review process that the manual is fully precise,
>>>> and perhaps to insist that the proposal has a note saying it will be made
>>>> precise in the course of implementation -- but I don't think we need this
>>>> to happen before acceptance. Sometimes the details are easier to work out
>>>> during implementation and can be informed by the tiny bit of experience
>>>> gained writing tests, etc.
>>>>
>>>> Richard
>>>>
>>>> PS: The viewpoint here -- to work out final details late -- is informed
>>>> by the common practice at Jane Street. We sketch out a broad idea with a
>>>> bunch of examples, but we write down the final specification only after
>>>> implementing. This is so much easier, because it makes the specification
>>>> process iterative with implementation.
>>>>
>>>> On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones <
>>>> simon.peytonjones at gmail.com> wrote:
>>>>
>>>> I'm content to accept, but only when the specification is made precise.
>>>>
>>>> Simon
>>>>
>>>> On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg <rae at richarde.dev>
>>>> wrote:
>>>>
>>>>> After some conversation on the ticket, I'd like to vote for acceptance
>>>>> here.
>>>>>
>>>>> Richard
>>>>>
>>>>> > On Jan 1, 2024, at 9:46 AM, Richard Eisenberg <rae at richarde.dev>
>>>>> wrote:
>>>>> >
>>>>> > Yes that's true of course, but if we had a design that could cover
>>>>> raw strings as well, then we have one fewer quoting construct. I guess the
>>>>> real question is: do we need the ability to toggle between multiline and
>>>>> raw separately? That is, right now we have cooked single-line strings. This
>>>>> proposal is for cooked multiline strings, leaving raw strings for a
>>>>> separate proposal. But maybe we only need cooked single-line strings and
>>>>> raw multiline ones? That would be simpler.
>>>>> >
>>>>> > I think wisdom from other languages would be helpful here. I will
>>>>> post on the ticket.
>>>>> >
>>>>> > Richard
>>>>> >
>>>>> >> On Dec 31, 2023, at 12:04 PM, Eric Seidel <eric at seidel.io> wrote:
>>>>> >>
>>>>> >>
>>>>> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae at richarde.dev>
>>>>> wrote:
>>>>> >>>
>>>>> >>> On the other hand, I'm a little worried that this doesn't have
>>>>> support for raw strings. That is, even with this, there will still be some
>>>>> users who reach for quasiquotes for multi-line strings, if those strings
>>>>> contain backslashes.
>>>>> >>
>>>>> >> I had a similar thought at first, but I think raw strings can be
>>>>> added independently of this proposal. So long as we are not closing the
>>>>> door to a future addition I think it is fine to take incremental steps.
>>>>> >
>>>>>
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>>
>>>>
>>>
>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240110/488a46d4/attachment.html>

From simon.peytonjones at gmail.com  Thu Jan 11 09:00:37 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 11 Jan 2024 09:00:37 +0000
Subject: [ghc-steering-committee] Secretary of the GHC Steering Committee
Message-ID: <CAJKmMz9d+JncAP8A2VGTwSC8dXuJ1G7hnkqOa7090a+j_xhN-A@mail.gmail.com>

Dear GHC Steering Committee

Joachim's term of membership in the GHC SC comes to an end in March, and he
wants to stand down as our Secretary.

Joachim, you have done a fantastic job as our secretary, nudging us with
regular status updates, making sure we hold membership nomination
processes, and much more besides.  You have made sure that we function well
as a committee, and I for one have leaned heavily on your support.  Thank
you so much.

Would anyone else like to be Secretary?  I am delighted to say that Adam is
willing to serve, but if anyone else would like to join in or share the
role, that would be great too.   Thank you Adam!

RSVP!

Thanks again Joachim.

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240111/e7ca76a4/attachment-0001.html>

From adam at well-typed.com  Thu Jan 11 09:54:46 2024
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 11 Jan 2024 09:54:46 +0000
Subject: [ghc-steering-committee] #493: SPECIALISE with expressions,
 rec: accept
In-Reply-To: <beba9def-eddd-4b52-b676-8e2509c66dba@app.fastmail.com>
References: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com>
 <CAJKmMz-t6=D--9zWbuNotpJbdmx0q12fiO0=jYrAic4ykx8-1A@mail.gmail.com>
 <beba9def-eddd-4b52-b676-8e2509c66dba@app.fastmail.com>
Message-ID: <26ec8e4a-3fd2-4cde-b153-dd9a238569aa@well-typed.com>

Hi everyone,

I believe there is broad consensus to accept this proposal. One point of 
detail that has arisen on the proposal thread 
(https://github.com/ghc-proposals/ghc-proposals/pull/493#issuecomment-1831697143) 
is whether to deprecate and remove the awkward and undocumented 
multi-type form

     {-# SPECIALISE f :: Int -> Int
                      , Bool -> Bool
                      , Float -> Float #-}

since users can equally well write the clearer

     {-# SPECIALISE f :: Int -> Int #-}
     {-# SPECIALISE f :: Bool -> Bool #-}
     {-# SPECIALISE f :: Float -> Float #-}

The current text of the proposal retains the multi-type form, but 
discussion on the proposal thread suggests deprecating it instead, 
subject to the usual requirement that if/when this is implemented, GHC 
will issue a warning and continue to accept the old syntax for at least 
3 releases before completely removing it.

I suggest we accept the proposal on the basis that it will be amended to 
deprecate the multi-type form. If you disagree, please object in the 
next week or so.

Cheers,

Adam



On 19/12/2023 03:02, Eric Seidel wrote:
> Apologies, this sounds like an obvious win. +1
> 
> On Mon, Dec 18, 2023, at 04:36, Simon Peyton Jones wrote:
>> Eric, Joachim, Chris
>>
>> You have not yet responded (I think) to Adam's recommendation.    RSVP!
>>
>> https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing
>>
>> Simon
>>
>> On Wed, 29 Nov 2023 at 08:25, Adam Gundry <adam at well-typed.com> wrote:
>>> Dear all,
>>>
>>> Richard and Simon propose to generalise SPECIALISE pragmas to allow
>>> expressions, not just type signatures:
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/493
>>> https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst
>>>
>>> This does not add anything fundamentally new, because such SPECIALISE
>>> pragmas can be translated using the existing RULES machinery, but it
>>> does make several idioms substantially more convenient:
>>>
>>>    * Using type applications in a SPECIALISE pragma to avoid repetition
>>>
>>>    * Manual call-pattern specialisation
>>>
>>>    * Loop unrolling
>>>
>>> Thus I propose we accept this proposal.
>>>
>>> Cheers,
>>>
>>> Adam


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From arnaud.spiwack at tweag.io  Thu Jan 11 13:06:31 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 11 Jan 2024 14:06:31 +0100
Subject: [ghc-steering-committee] #493: SPECIALISE with expressions,
	rec: accept
In-Reply-To: <26ec8e4a-3fd2-4cde-b153-dd9a238569aa@well-typed.com>
References: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com>
 <CAJKmMz-t6=D--9zWbuNotpJbdmx0q12fiO0=jYrAic4ykx8-1A@mail.gmail.com>
 <beba9def-eddd-4b52-b676-8e2509c66dba@app.fastmail.com>
 <26ec8e4a-3fd2-4cde-b153-dd9a238569aa@well-typed.com>
Message-ID: <CAGwnsnmo704VsXMQjjzWURMmJoSzap7qun_yFHxfZrVV2T7dtQ@mail.gmail.com>

Simon amended the proposal to say just that more or less at the same time
as your email.

At any rate, I think we should accept the proposal regardless of
deprecation. Both choices are equally reasonable in my opinion.

On Thu, 11 Jan 2024 at 10:55, Adam Gundry <adam at well-typed.com> wrote:

> Hi everyone,
>
> I believe there is broad consensus to accept this proposal. One point of
> detail that has arisen on the proposal thread
> (
> https://github.com/ghc-proposals/ghc-proposals/pull/493#issuecomment-1831697143)
>
> is whether to deprecate and remove the awkward and undocumented
> multi-type form
>
>      {-# SPECIALISE f :: Int -> Int
>                       , Bool -> Bool
>                       , Float -> Float #-}
>
> since users can equally well write the clearer
>
>      {-# SPECIALISE f :: Int -> Int #-}
>      {-# SPECIALISE f :: Bool -> Bool #-}
>      {-# SPECIALISE f :: Float -> Float #-}
>
> The current text of the proposal retains the multi-type form, but
> discussion on the proposal thread suggests deprecating it instead,
> subject to the usual requirement that if/when this is implemented, GHC
> will issue a warning and continue to accept the old syntax for at least
> 3 releases before completely removing it.
>
> I suggest we accept the proposal on the basis that it will be amended to
> deprecate the multi-type form. If you disagree, please object in the
> next week or so.
>
> Cheers,
>
> Adam
>
>
>
> On 19/12/2023 03:02, Eric Seidel wrote:
> > Apologies, this sounds like an obvious win. +1
> >
> > On Mon, Dec 18, 2023, at 04:36, Simon Peyton Jones wrote:
> >> Eric, Joachim, Chris
> >>
> >> You have not yet responded (I think) to Adam's recommendation.    RSVP!
> >>
> >>
> https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing
> >>
> >> Simon
> >>
> >> On Wed, 29 Nov 2023 at 08:25, Adam Gundry <adam at well-typed.com> wrote:
> >>> Dear all,
> >>>
> >>> Richard and Simon propose to generalise SPECIALISE pragmas to allow
> >>> expressions, not just type signatures:
> >>>
> >>> https://github.com/ghc-proposals/ghc-proposals/pull/493
> >>>
> https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst
> >>>
> >>> This does not add anything fundamentally new, because such SPECIALISE
> >>> pragmas can be translated using the existing RULES machinery, but it
> >>> does make several idioms substantially more convenient:
> >>>
> >>>    * Using type applications in a SPECIALISE pragma to avoid repetition
> >>>
> >>>    * Manual call-pattern specialisation
> >>>
> >>>    * Loop unrolling
> >>>
> >>> Thus I propose we accept this proposal.
> >>>
> >>> Cheers,
> >>>
> >>> Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240111/fccc4334/attachment.html>

From rae at richarde.dev  Fri Jan 12 01:22:42 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 12 Jan 2024 01:22:42 +0000
Subject: [ghc-steering-committee] #626: Amendment of Visible Forall in
 Types, recommendation: Accept
In-Reply-To: <CAGwnsnmgqk8qzueATWiWg4_81Av2c1S+tyRaECxn5iWFZV674Q@mail.gmail.com>
References: <CAGwnsnkpCa2NMPBPDd_hEA=vHQLbMzvtr78+EJsYQDa5Qcu+DQ@mail.gmail.com>
 <CAJKmMz9+-xpr-X5V+4A=1Ctuvs9Xd+5oW8UgzRbZ8d=sQqU_tQ@mail.gmail.com>
 <CAGwnsnkM7FPRAXeTik5g2Na3s+Dzv2ifAhkzpukydaQ8Hz0NTQ@mail.gmail.com>
 <010f018cca3e8920-cd21c435-0d3e-4c0b-8ba1-e4319539ed5d-000000@us-east-2.amazonses.com>
 <CAGwnsnmgqk8qzueATWiWg4_81Av2c1S+tyRaECxn5iWFZV674Q@mail.gmail.com>
Message-ID: <010f018cfb43a06a-c6cd0a9d-9100-4de6-94d4-63a211d9e75b-000000@us-east-2.amazonses.com>

(For what it's worth, my suggestion was accepted and has been incorporated into the proposal.)

> On Jan 9, 2024, at 10:43 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> Any other thoughts? If not, I'll consider this proposal accepted at the end of this week.
> 
> On Tue, 2 Jan 2024 at 13:55, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> I support the amendment. I made one small suggestion, but I wish to vote for acceptance regardless of the status of this suggestion.
> 
> Richard
> 
>> On Dec 22, 2023, at 9:20 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>> 
>> I realised today that we haven't completed the vote on this. This is really a very simple proposal, let's not spend too long on this. I'll be on holiday for the next two weeks, I'm a bit embarrassed to send this email only now. But please opine soon. I'd like to be able to give an answer soon after I'm back (say on the 12th January)
>> 
>> Best,
>> Arnaud
>> 
>> On Mon, 11 Dec 2023 at 11:06, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> I recommend acceptance too.  It's all very fine detail.
>> 
>> The actual diff seems quite large but that's because I encouraged Vlad to take the opportunity to clarity the rather cryptic sentence in the original #218, namely "The syntactic descriptions here applying to expressions apply equally to patterns, though we will continue to discuss only expressions."  Instead it is all spelled out much more explicitly, which is way better.  Indeed spelling it out showed up a dark corner to do with view patterns, hence the icky stuff Arnaud mentions.
>> 
>> Simon
>> 
>> 
>> On Mon, 11 Dec 2023 at 09:56, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>> Dear all,
>> 
>> Vlad is proposing to amend his own proposal https://github.com/ghc-proposals/ghc-proposals/pull/626 <https://github.com/ghc-proposals/ghc-proposals/pull/626>
>> 
>> Being an amendment, it's, as always, not as straightforward to consume, but Vlad gives us a good summary of the changes in his pull-request description.
>> 
>> All in all, it's almost entirely straightforward clarification. There are two items of notice: patterns for visible forall arguments were specified as: only variable or wildcard. The amendment changes it to allow data constructors applied to (0 or more) patterns as well. The amended version is consistent with how patterns for invisible forall arguments are specified. The second, and this one is for Moritz, is a small change in the parsing of view patterns (it does break two packages at least on Hackage, but I actually don't quite understand how the change can affect semantics. It's that tiny. Vlad proposes 3 releases with warning before effecting the change).
>> 
>> Maybe there's a third item: `p -> q` parses differently depending on whether ViewPattern or RequiredTypeArguments (or both) is turned on. This is kind of icky, I suppose. But in the case where both are on, then ViewPattern wins, so there's no real harm in it.
>> 
>> Do pay some attention to the new items in the alternatives section.
>> 
>> Anyway, I recommend we accept.
>> 
>> -- 
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> 
>> 
>> -- 
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240112/d4b0f3de/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Jan 12 10:08:14 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 12 Jan 2024 11:08:14 +0100
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
Message-ID: <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>

At Richard's prompting, I've added the following alternative to the
proposal (the current proposal is the most conservative of the two, which
we can choose to stick to if we're unsure). I'm copying the alternative
here because rendering seems to be broken on Github right now.

I'm rather agnostic on which side we choose, to be honest. Anyone with
medium-to-strong opinions on the question?


Restrictions of multiplicity-annotated let bindings
---------------------------------------------------

The proposal specifies that a multiplicity annotated non-variable let
binding ``let %p pat``
must be such that ``pat = !pat'`` even if ``p = 'Many``. It is easy to
lift this restriction on two dimension:

- We can say, instead, that patterns not of the form ``!pat'`` emit a
  ``p ~ 'Many`` constraint instead. They already do (for the sake of
  inference), so this is strictly less code.
- We can generalise to more strict patterns. For instance, we don't
  need to require a ``!`` if ``-XStrict`` is on, we can have patterns
  of the form ``(!pat')`` (with additional parentheses). This is a few
  lines of codes, inference actually already does this in my
  implementation, so it's already paid for (though it does annoyingly
  mostly duplicate another definition of strict pattern which I
  couldn't find a way to factor as a single function, I don't like
  this).

The reason that motivated the stronger restriction is to improve error
messages, because we can then error out with “multiplicity-annotated
let-bound patterns must be of the form !pat”, instead of the more
mysterious “Couldn't unify 'Many with 'One”
(see `#23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586>`_).
But maybe the additional restrictions are more surprising than the
error messages are helpful.

On Mon, 8 Jan 2024 at 10:07, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> I support acceptance.  Let's land this soon.
>
> Simon
>
> On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> Hi all,
>>
>> I've reviewed Arnaud's
>> https://github.com/ghc-proposals/ghc-proposals/pull/624 and wish to
>> recommend acceptance.
>>
>> The proposal is an amendment to the proposal for linear types, adding
>> support for linear let bindings.
>>
>> Today, if you have
>>
>> f :: T %1-> T
>> f t = let t2 = t in t2
>>
>> you'll get an error because t2 is not linear. The only way to bind a
>> linear variable is via a `case`, never a `let` or `where`. This is
>> annoying. With this proposal, the little program above is accepted, with an
>> inferred linearity restriction on t2. Users can also annotated their lets
>> like `let %1 x = ... in ...`. Bindings in `where` clauses can also be
>> inferred or annotated as linear.
>>
>> There is a downside, of course: linear bindings have various
>> restrictions, chiefly that they must be strict bindings (because
>> projections are hard with linear types) and that bindings cannot be
>> generalized. I'm a little unsure that the choices in the proposal
>> (particularly around generalization) are the best for users, but I think
>> the best way to learn is to experiment. In my understanding, the community
>> knows that -XLinearTypes is subject to revision, and so I think we should
>> just blast ahead, revising if and when necessary.
>>
>> Please share your thoughts!
>>
>> Thanks,
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240112/240ed780/attachment.html>

From arnaud.spiwack at tweag.io  Fri Jan 12 10:12:08 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 12 Jan 2024 11:12:08 +0100
Subject: [ghc-steering-committee] #626: Amendment of Visible Forall in
 Types, recommendation: Accept
In-Reply-To: <010f018cfb43a06a-c6cd0a9d-9100-4de6-94d4-63a211d9e75b-000000@us-east-2.amazonses.com>
References: <CAGwnsnkpCa2NMPBPDd_hEA=vHQLbMzvtr78+EJsYQDa5Qcu+DQ@mail.gmail.com>
 <CAJKmMz9+-xpr-X5V+4A=1Ctuvs9Xd+5oW8UgzRbZ8d=sQqU_tQ@mail.gmail.com>
 <CAGwnsnkM7FPRAXeTik5g2Na3s+Dzv2ifAhkzpukydaQ8Hz0NTQ@mail.gmail.com>
 <010f018cca3e8920-cd21c435-0d3e-4c0b-8ba1-e4319539ed5d-000000@us-east-2.amazonses.com>
 <CAGwnsnmgqk8qzueATWiWg4_81Av2c1S+tyRaECxn5iWFZV674Q@mail.gmail.com>
 <010f018cfb43a06a-c6cd0a9d-9100-4de6-94d4-63a211d9e75b-000000@us-east-2.amazonses.com>
Message-ID: <CAGwnsnkVMdTykbuFd9+ujaN1yz4My_MsC_Aiwu46anEzXNetBg@mail.gmail.com>

I actually hadn't noticed, thanks Richard. For the record: said change
removes the icky ambiguity on `p -> q`, which is always parsed as a view
pattern.


On Fri, 12 Jan 2024 at 02:22, Richard Eisenberg <rae at richarde.dev> wrote:

> (For what it's worth, my suggestion was accepted and has been incorporated
> into the proposal.)
>
> On Jan 9, 2024, at 10:43 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
> Any other thoughts? If not, I'll consider this proposal accepted at the
> end of this week.
>
> On Tue, 2 Jan 2024 at 13:55, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> I support the amendment. I made one small suggestion, but I wish to vote
>> for acceptance regardless of the status of this suggestion.
>>
>> Richard
>>
>> On Dec 22, 2023, at 9:20 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> I realised today that we haven't completed the vote on this. This is
>> really a very simple proposal, let's not spend too long on this. I'll be on
>> holiday for the next two weeks, I'm a bit embarrassed to send this email
>> only now. But please opine soon. I'd like to be able to give an answer soon
>> after I'm back (say on the 12th January)
>>
>> Best,
>> Arnaud
>>
>> On Mon, 11 Dec 2023 at 11:06, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> I recommend acceptance too.  It's all very fine detail.
>>>
>>> The actual diff seems quite large but that's because I encouraged Vlad
>>> to take the opportunity to clarity the rather cryptic sentence in the
>>> original #218, namely "The syntactic descriptions here applying to
>>> expressions apply equally to patterns, though we will continue to discuss
>>> only expressions."  Instead it is all spelled out much more explicitly,
>>> which is way better.  Indeed spelling it out showed up a dark corner to do
>>> with view patterns, hence the icky stuff Arnaud mentions.
>>>
>>> Simon
>>>
>>>    -
>>>
>>>
>>> On Mon, 11 Dec 2023 at 09:56, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> Vlad is proposing to amend his own proposal
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/626
>>>>
>>>> Being an amendment, it's, as always, not as straightforward to consume,
>>>> but Vlad gives us a good summary of the changes in his pull-request
>>>> description.
>>>>
>>>> All in all, it's almost entirely straightforward clarification. There
>>>> are two items of notice: patterns for visible forall arguments were
>>>> specified as: only variable or wildcard. The amendment changes it to allow
>>>> data constructors applied to (0 or more) patterns as well. The amended
>>>> version is consistent with how patterns for invisible forall arguments are
>>>> specified. The second, and this one is for Moritz, is a small change in the
>>>> parsing of view patterns (it does break two packages at least on Hackage,
>>>> but I actually don't quite understand how the change can affect semantics.
>>>> It's that tiny. Vlad proposes 3 releases with warning before effecting the
>>>> change).
>>>>
>>>> Maybe there's a third item: `p -> q` parses differently depending on
>>>> whether ViewPattern or RequiredTypeArguments (or both) is turned on. This
>>>> is kind of icky, I suppose. But in the case where both are on, then
>>>> ViewPattern wins, so there's no real harm in it.
>>>>
>>>> Do pay some attention to the new items in the alternatives section.
>>>>
>>>> Anyway, I recommend we accept.
>>>>
>>>> --
>>>> Arnaud Spiwack
>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>
>
>

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240112/15ac4c82/attachment-0001.html>

From simon.peytonjones at gmail.com  Fri Jan 12 20:04:24 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 12 Jan 2024 20:04:24 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
Message-ID: <CAJKmMz8RKaGXkGrLJ=ov4f0QMMbeSEh=jw42rvrtkp9DpSO4DQ@mail.gmail.com>

I do not feel strongly.   Simpler is better.

It would be great to settle this proposal asap

-----------

BTW: proposals are not formatting for me: I just get shown the raw RST
file  E.g
https://github.com/tweag/ghc-proposals/blob/linear-lets/proposals/0111-linear-types.rst

What am I doing wrong?

Simon

On Fri, 12 Jan 2024 at 10:08, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> At Richard's prompting, I've added the following alternative to the
> proposal (the current proposal is the most conservative of the two, which
> we can choose to stick to if we're unsure). I'm copying the alternative
> here because rendering seems to be broken on Github right now.
>
> I'm rather agnostic on which side we choose, to be honest. Anyone with
> medium-to-strong opinions on the question?
>
>
> Restrictions of multiplicity-annotated let bindings
> ---------------------------------------------------
>
> The proposal specifies that a multiplicity annotated non-variable let
> binding ``let %p pat``
> must be such that ``pat = !pat'`` even if ``p = 'Many``. It is easy to
> lift this restriction on two dimension:
>
> - We can say, instead, that patterns not of the form ``!pat'`` emit a
>   ``p ~ 'Many`` constraint instead. They already do (for the sake of
>   inference), so this is strictly less code.
> - We can generalise to more strict patterns. For instance, we don't
>   need to require a ``!`` if ``-XStrict`` is on, we can have patterns
>   of the form ``(!pat')`` (with additional parentheses). This is a few
>   lines of codes, inference actually already does this in my
>   implementation, so it's already paid for (though it does annoyingly
>   mostly duplicate another definition of strict pattern which I
>   couldn't find a way to factor as a single function, I don't like
>   this).
>
> The reason that motivated the stronger restriction is to improve error
> messages, because we can then error out with “multiplicity-annotated
> let-bound patterns must be of the form !pat”, instead of the more
> mysterious “Couldn't unify 'Many with 'One”
> (see `#23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586>`_).
> But maybe the additional restrictions are more surprising than the
> error messages are helpful.
>
> On Mon, 8 Jan 2024 at 10:07, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I support acceptance.  Let's land this soon.
>>
>> Simon
>>
>> On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>>> Hi all,
>>>
>>> I've reviewed Arnaud's
>>> https://github.com/ghc-proposals/ghc-proposals/pull/624 and wish to
>>> recommend acceptance.
>>>
>>> The proposal is an amendment to the proposal for linear types, adding
>>> support for linear let bindings.
>>>
>>> Today, if you have
>>>
>>> f :: T %1-> T
>>> f t = let t2 = t in t2
>>>
>>> you'll get an error because t2 is not linear. The only way to bind a
>>> linear variable is via a `case`, never a `let` or `where`. This is
>>> annoying. With this proposal, the little program above is accepted, with an
>>> inferred linearity restriction on t2. Users can also annotated their lets
>>> like `let %1 x = ... in ...`. Bindings in `where` clauses can also be
>>> inferred or annotated as linear.
>>>
>>> There is a downside, of course: linear bindings have various
>>> restrictions, chiefly that they must be strict bindings (because
>>> projections are hard with linear types) and that bindings cannot be
>>> generalized. I'm a little unsure that the choices in the proposal
>>> (particularly around generalization) are the best for users, but I think
>>> the best way to learn is to experiment. In my understanding, the community
>>> knows that -XLinearTypes is subject to revision, and so I think we should
>>> just blast ahead, revising if and when necessary.
>>>
>>> Please share your thoughts!
>>>
>>> Thanks,
>>> Richard
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240112/79535aad/attachment.html>

From adam at well-typed.com  Sat Jan 13 20:00:42 2024
From: adam at well-typed.com (Adam Gundry)
Date: Sat, 13 Jan 2024 20:00:42 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
Message-ID: <b4dad401-e7fd-42e4-ba41-6b5247646e42@well-typed.com>

I haven't looked at this closely, but I'm happy to trust Arnaud and 
Richard's judgment and accept, especially since LinearTypes is at a very 
experimental stage.

Adam


On 12/01/2024 10:08, Arnaud Spiwack wrote:
> At Richard's prompting, I've added the following alternative to the 
> proposal (the current proposal is the most conservative of the two, 
> which we can choose to stick to if we're unsure). I'm copying the 
> alternative here because rendering seems to be broken on Github right now.
> 
> I'm rather agnostic on which side we choose, to be honest. Anyone with 
> medium-to-strong opinions on the question?
> 
> 
> Restrictions of multiplicity-annotated let bindings
> ---------------------------------------------------
> 
> The proposal specifies that a multiplicity annotated non-variable let 
> binding ``let %p pat``
> must be such that ``pat = !pat'`` even if ``p = 'Many``. It is easy to
> lift this restriction on two dimension:
> 
> - We can say, instead, that patterns not of the form ``!pat'`` emit a
>    ``p ~ 'Many`` constraint instead. They already do (for the sake of
>    inference), so this is strictly less code.
> - We can generalise to more strict patterns. For instance, we don't
>    need to require a ``!`` if ``-XStrict`` is on, we can have patterns
>    of the form ``(!pat')`` (with additional parentheses). This is a few
>    lines of codes, inference actually already does this in my
>    implementation, so it's already paid for (though it does annoyingly
>    mostly duplicate another definition of strict pattern which I
>    couldn't find a way to factor as a single function, I don't like
>    this).
> 
> The reason that motivated the stronger restriction is to improve error
> messages, because we can then error out with “multiplicity-annotated
> let-bound patterns must be of the form !pat”, instead of the more
> mysterious “Couldn't unify 'Many with 'One”
> (see `#23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586 
> <https://gitlab.haskell.org/ghc/ghc/-/issues/23586>>`_).
> But maybe the additional restrictions are more surprising than the
> error messages are helpful.
> 
> On Mon, 8 Jan 2024 at 10:07, Simon Peyton Jones 
> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>     I support acceptance.  Let's land this soon.
> 
>     Simon
> 
>     On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev
>     <mailto:rae at richarde.dev>> wrote:
> 
>         Hi all,
> 
>         I've reviewed Arnaud's
>         https://github.com/ghc-proposals/ghc-proposals/pull/624
>         <https://github.com/ghc-proposals/ghc-proposals/pull/624> and
>         wish to recommend acceptance.
> 
>         The proposal is an amendment to the proposal for linear types,
>         adding support for linear let bindings.
> 
>         Today, if you have
> 
>         f :: T %1-> T
>         f t = let t2 = t in t2
> 
>         you'll get an error because t2 is not linear. The only way to
>         bind a linear variable is via a `case`, never a `let` or
>         `where`. This is annoying. With this proposal, the little
>         program above is accepted, with an inferred linearity
>         restriction on t2. Users can also annotated their lets like `let
>         %1 x = ... in ...`. Bindings in `where` clauses can also be
>         inferred or annotated as linear.
> 
>         There is a downside, of course: linear bindings have various
>         restrictions, chiefly that they must be strict bindings (because
>         projections are hard with linear types) and that bindings cannot
>         be generalized. I'm a little unsure that the choices in the
>         proposal (particularly around generalization) are the best for
>         users, but I think the best way to learn is to experiment. In my
>         understanding, the community knows that -XLinearTypes is subject
>         to revision, and so I think we should just blast ahead, revising
>         if and when necessary.
> 
>         Please share your thoughts!
> 
>         Thanks,
>         Richard


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From adam at well-typed.com  Sat Jan 13 20:41:59 2024
From: adam at well-typed.com (Adam Gundry)
Date: Sat, 13 Jan 2024 20:41:59 +0000
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <CAJKmMz_GbawR14jEgc5YoMXuNH_FbA5p5ps5ppQwnPAacQ70+A@mail.gmail.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
 <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
 <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>
 <CAJKmMz9rE-bVou1XUE+5fEF_Cw8EtrbH+8RhstOZcu5OLPUSWA@mail.gmail.com>
 <010f018ccf623071-9dd56897-7356-4ca2-835f-5a4df09f963e-000000@us-east-2.amazonses.com>
 <CAJKmMz9jXWzeN6THtD1SbE9wH=aFMD4XPJyLrs_=wANioJku6A@mail.gmail.com>
 <010f018ccf6dc808-374c3c04-defd-4ca5-b5fe-13db67d8e556-000000@us-east-2.amazonses.com>
 <CAJKmMz_GbawR14jEgc5YoMXuNH_FbA5p5ps5ppQwnPAacQ70+A@mail.gmail.com>
Message-ID: <afdb3f88-cb9f-485a-9645-625d9e4107af@well-typed.com>

The multiline string proposal looks good to me. Thanks Simon for helping 
polish the spec.

On the meta point, I agree with Simon's position here: we should avoid 
giving unconditional acceptance to underspecified proposals, only to 
potentially discover problems later. But where a proposal is not 
precisely specified, it would be preferable to accept in principle (so 
the author is not left wondering whether the idea has a chance) and then 
ask and support the author to finish the spec before merging the PR.

Adam


On 03/01/2024 13:13, Simon Peyton Jones wrote:
>     But there is! Code review, for the user manual entry.
> 
> 
> I just think that often will not happen.
> 
> I am also genuinely unclear about what the spec *is*.   I see no 
> downside, and significant upside, in resolving that now rather than 
> kicking it down the road.   I have read the proposal.  I have it paged 
> in.  I don't want to repeat that process in three weeks, or three 
> months, or three years.
> 
> If the author wants to write a user manual entry and put that as the 
> "proposed change spec" that would be fine with me.  I'm not asking for 
> duplicated effort.
> 
> Simon
> 
> On Wed, 3 Jan 2024 at 13:05, Richard Eisenberg <rae at richarde.dev 
> <mailto:rae at richarde.dev>> wrote:
> 
> 
> 
>>     On Jan 3, 2024, at 7:56 AM, Simon Peyton Jones
>>     <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>>     wrote:
>>
>>     If there is a consensus to accept, we can say "Accept provided you
>>     make the spec precise, and that process does not throw up any
>>     unexpected surprises".  I agree that requiring a fully-precise
>>     spec for a subsequently-rejected proposal is dispiriting.
>>
>>     But I worry that if we kick the can down the road
>>
>>       * there is no mechanism to ensure subsequent precision
>     But there is! Code review, for the user manual entry.
>>
>>       * code reviewers have no spec wrt which to review the code
>     This can be problematic -- but reviewers should then insist that the
>     manual entry is precise so that they can review the code.
> 
>>     so maybe it never gets done at all.
>>
>>     Simon
>>
>>     On Wed, 3 Jan 2024 at 12:52, Richard Eisenberg <rae at richarde.dev
>>     <mailto:rae at richarde.dev>> wrote:
>>
>>
>>
>>>         On Jan 3, 2024, at 7:47 AM, Simon Peyton Jones
>>>         <simon.peytonjones at gmail.com
>>>         <mailto:simon.peytonjones at gmail.com>> wrote:
>>>
>>>         But why wait? 
>>
>>         To reduce the burden of the proposal process. From the point
>>         of view of the proposer, putting yet more time into an
>>         as-yet-unaccepted proposal is a hoop to jump through, with
>>         uncertain outcome.
>>
>>         As we can observe, writing precise specifications is generally
>>         not easy. (If it were easy, then we should expect most
>>         proposals to come with one. But almost all proposals are
>>         insufficiently precise upon inspection.) I'm just trying to
>>         nudge us toward making the process easier (for us, too!).
>>
>>         Richard
>>
>>
>>>         There is no implementation-related uncertainty here.  It's
>>>         just a question of writing a precise spec.  It's not even
>>>         difficult to do!
>>>
>>>         Sometimes making the spec precise throws up unexpected wrinkles.
>>>
>>>         I'm not against postponing things where the implementation
>>>         may influence details of the spec.  But that's not the case
>>>         here, I think.
>>>
>>>         Simon
>>>
>>>         On Wed, 3 Jan 2024 at 12:43, Richard Eisenberg
>>>         <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>>>
>>>             I agree that some aspects of this proposal are not as
>>>             precise as I'd like. But actually I think we should
>>>             accept before these last few details are worked out.
>>>             Unless I'm mistaken, there's not a worry that the
>>>             specific choices will change our minds, and the details
>>>             will have to be resolved in the course of implementation.
>>>             Ideally, the proposer will come back and update the
>>>             proposal. However, the proposal is not the long-lasting
>>>             record of the specification; the user manual is. (By
>>>             contrast, the proposal is the long-lasting record of the
>>>             motivation / discussion / alternatives.) So I would
>>>             insist in the code-review process that the manual is
>>>             fully precise, and perhaps to insist that the proposal
>>>             has a note saying it will be made precise in the course
>>>             of implementation -- but I don't think we need this to
>>>             happen before acceptance. Sometimes the details are
>>>             easier to work out during implementation and can be
>>>             informed by the tiny bit of experience gained writing
>>>             tests, etc.
>>>
>>>             Richard
>>>
>>>             PS: The viewpoint here -- to work out final details late
>>>             -- is informed by the common practice at Jane Street. We
>>>             sketch out a broad idea with a bunch of examples, but we
>>>             write down the final specification only after
>>>             implementing. This is so much easier, because it makes
>>>             the specification process iterative with implementation.
>>>
>>>>             On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones
>>>>             <simon.peytonjones at gmail.com
>>>>             <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>
>>>>             I'm content to accept, but only when the specification
>>>>             is made precise.
>>>>
>>>>             Simon
>>>>
>>>>             On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg
>>>>             <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>>>>
>>>>                 After some conversation on the ticket, I'd like to
>>>>                 vote for acceptance here.
>>>>
>>>>                 Richard
>>>>
>>>>                 > On Jan 1, 2024, at 9:46 AM, Richard Eisenberg
>>>>                 <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>>>>                 >
>>>>                 > Yes that's true of course, but if we had a design
>>>>                 that could cover raw strings as well, then we have
>>>>                 one fewer quoting construct. I guess the real
>>>>                 question is: do we need the ability to toggle
>>>>                 between multiline and raw separately? That is, right
>>>>                 now we have cooked single-line strings. This
>>>>                 proposal is for cooked multiline strings, leaving
>>>>                 raw strings for a separate proposal. But maybe we
>>>>                 only need cooked single-line strings and raw
>>>>                 multiline ones? That would be simpler.
>>>>                 >
>>>>                 > I think wisdom from other languages would be
>>>>                 helpful here. I will post on the ticket.
>>>>                 >
>>>>                 > Richard
>>>>                 >
>>>>                 >> On Dec 31, 2023, at 12:04 PM, Eric Seidel
>>>>                 <eric at seidel.io <mailto:eric at seidel.io>> wrote:
>>>>                 >>
>>>>                 >>
>>>>                 >>> On Dec 29, 2023, at 07:19, Richard Eisenberg
>>>>                 <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>>>>                 >>>
>>>>                 >>> On the other hand, I'm a little worried that
>>>>                 this doesn't have support for raw strings. That is,
>>>>                 even with this, there will still be some users who
>>>>                 reach for quasiquotes for multi-line strings, if
>>>>                 those strings contain backslashes.
>>>>                 >>
>>>>                 >> I had a similar thought at first, but I think raw
>>>>                 strings can be added independently of this proposal.
>>>>                 So long as we are not closing the door to a future
>>>>                 addition I think it is fine to take incremental steps.
>>>>                 >
>>>>


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From adam at well-typed.com  Sat Jan 13 21:18:53 2024
From: adam at well-typed.com (Adam Gundry)
Date: Sat, 13 Jan 2024 21:18:53 +0000
Subject: [ghc-steering-committee] Modifiers and #512: NoFieldSelectors
In-Reply-To: <CAGwnsn=_si=gPozgPaLf+DYq=8QVVccpD+Pr_+aPHhAdEkiFxg@mail.gmail.com>
References: <CAHZ0NLpmzcMREu4vEtDZVqpeceH7SCECh3tC47OUTMu5okAQiQ@mail.gmail.com>
 <CAJKmMz88uO4Y3W6RJR3b9qQNxg-30RPkLrkGYKJoBeLpJULn9g@mail.gmail.com>
 <010f018c6852632f-a9b0eed2-0804-46a8-aa43-ff9ab3e1e50d-000000@us-east-2.amazonses.com>
 <CAGwnsn=_si=gPozgPaLf+DYq=8QVVccpD+Pr_+aPHhAdEkiFxg@mail.gmail.com>
Message-ID: <912c0b5e-4571-4101-b7a2-21167484cfc4@well-typed.com>

It's certainly unfortunate that this proposal has been stalled for so long.

I think there is rough consensus that modifiers-style syntax would be 
preferable to the pragma syntax suggested in the proposal. That's 
slightly different from requiring Modifiers in its full glory to be 
implemented prior to this proposal, because one could implement the 
proposal more directly (e.g. having the parser recognise 
%NoFieldSelectors just as it could recognise {-# NoFieldSelectors #-}). 
Thus we don't need a synchronisation point: if necessary the amended 
NoFieldSelectors proposal can be implemented first and then the 
Modifiers implementation can generalise it.

So I'd suggest we "conditionally accept" the proposal, on the basis that 
it is amended to use modifier syntax, giving a clear signal to the 
author that the proposal isn't going to get stuck again. By 
"conditionally accept" I mean we wouldn't insist on another full round 
of committee review once the revisions are made.

Also, given the delays, I think it would be best if one of us offers to 
take care of the work of revising the proposal, rather than requiring 
the author to do it (but of course asking their opinion on this proposed 
approach).

Does this sound reasonable? Some of this may be what Vlad means by 
"Revise the proposal to use modifiers-based syntax and then accept", I'm 
not sure.

Cheers,

Adam


On 18/12/2023 08:59, Arnaud Spiwack wrote:
> Here's my thought.
> 
> If the modifiers implementation arrives before #512 is implemented, then 
> it's fair to amend the proposal. If the modifiers implementation arrives 
> after #512 is implemented, then it will be time to amend the proposal, 
> add the modifier version of #512, and deprecate the pragma. If there 
> hasn't been a release of the pragma version, then it can be deleted 
> entirely. I don't really feel there needs to be additional 
> synchronisation points imposed onto contributors.
> 
> On Thu, 14 Dec 2023 at 13:35, Richard Eisenberg <rae at richarde.dev 
> <mailto:rae at richarde.dev>> wrote:
> 
>     Concur. Let's boldly go into the future with modifiers. :)
> 
>     Thanks, Vlad.
> 
>     Richard
> 
>>     On Dec 11, 2023, at 4:31 PM, Simon Peyton Jones
>>     <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>>     wrote:
>>
>>         If we choose to revise, I volunteer to implement Modifiers in
>>         time for GHC 9.12 
>>
>>
>>     Like Joachim, this changes the situation a lot.  Thank you for
>>     offering.  You are an excellent implementor, and if you say you'll
>>     do it, I'm sure you will.  Don't forget that, to be useful for the
>>     author, the modifiers need to be in Template-Haskell-generated
>>     syntax too.
>>
>>     With that in mind:
>>
>>     * [ x] Revise the proposal to use modifiers-based syntax and then
>>     accept
>>
>>     I'm sure the author will be happy to use modifier syntax -- he
>>     just needs to be sure that doing so won't block the feature and
>>     your offer gives him that surety.
>>
>>     Simon
>>
>>     On Mon, 11 Dec 2023 at 12:40, Vladislav Zavialov
>>     <vlad.z.4096 at gmail.com <mailto:vlad.z.4096 at gmail.com>> wrote:
>>
>>         Dear Committee Members,
>>
>>         Our previous discussion regarding #512 was inconclusive.
>>
>>         Thread 1:
>>         https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002991.html <https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002991.html>
>>         Thread 2:
>>         https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/003015.html <https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/003015.html>
>>
>>         #512 is the proposal that introduces per-declaration,
>>         per-constructor, and per-field NoFieldSelectors annotations.
>>
>>         I'm not quite sure how to summarize the discussion because
>>         everyone seems to have a unique view. But it all revolves
>>         around a syntactic issue: should the proposal use pragma-based
>>         syntax or modifiers-based syntax?
>>
>>         Here are two facts to inform your opinion:
>>
>>         1. The Modifiers proposal is accepted, and it makes sense to
>>         use it for the proposed feature
>>         2. The Modifiers proposal is, however, unimplemented
>>
>>         So at the moment #512 says that we'd first introduce the
>>         pragma-based syntax, and when Modifiers are implemented we
>>         could deprecate the pragma-based syntax in favor of Modifiers.
>>
>>         I am *strongly* opposed to introducing a feature that we know
>>         is destined for deprecation. But not everyone shares this
>>         attitude, apparently, so let's vote.
>>
>>         Here are the options. Select all that you find acceptable
>>         (multiple-choice):
>>         * [ ] Accept the proposal with pragma-based syntax, then
>>         deprecate it and switch to modifiers-based syntax
>>         * [ ] Accept the proposal with pragma-based syntax, do not
>>         switch to modifiers-based syntax
>>         * [ ] Revise the proposal to use modifiers-based syntax and
>>         then accept
>>         * [ ] Reject the proposal regardless of syntax
>>
>>         Before you vote, let me try to sway you towards the "revise"
>>         option. If we choose to revise, I volunteer to implement
>>         Modifiers in time for GHC 9.12. I believe Modifiers are a
>>         splendid idea and I envision many good uses for them.
>>
>>         Vlad


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From simon.peytonjones at gmail.com  Sat Jan 13 21:53:21 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sat, 13 Jan 2024 21:53:21 +0000
Subject: [ghc-steering-committee] Modifiers and #512: NoFieldSelectors
In-Reply-To: <912c0b5e-4571-4101-b7a2-21167484cfc4@well-typed.com>
References: <CAHZ0NLpmzcMREu4vEtDZVqpeceH7SCECh3tC47OUTMu5okAQiQ@mail.gmail.com>
 <CAJKmMz88uO4Y3W6RJR3b9qQNxg-30RPkLrkGYKJoBeLpJULn9g@mail.gmail.com>
 <010f018c6852632f-a9b0eed2-0804-46a8-aa43-ff9ab3e1e50d-000000@us-east-2.amazonses.com>
 <CAGwnsn=_si=gPozgPaLf+DYq=8QVVccpD+Pr_+aPHhAdEkiFxg@mail.gmail.com>
 <912c0b5e-4571-4101-b7a2-21167484cfc4@well-typed.com>
Message-ID: <CAJKmMz-Ln6knLQFEZBOssdUWTSS-+5wFcMTRKMgAw4U9mYW2Wg@mail.gmail.com>

I agree with this.

Simon

On Sat, 13 Jan 2024 at 21:19, Adam Gundry <adam at well-typed.com> wrote:

> It's certainly unfortunate that this proposal has been stalled for so long.
>
> I think there is rough consensus that modifiers-style syntax would be
> preferable to the pragma syntax suggested in the proposal. That's
> slightly different from requiring Modifiers in its full glory to be
> implemented prior to this proposal, because one could implement the
> proposal more directly (e.g. having the parser recognise
> %NoFieldSelectors just as it could recognise {-# NoFieldSelectors #-}).
> Thus we don't need a synchronisation point: if necessary the amended
> NoFieldSelectors proposal can be implemented first and then the
> Modifiers implementation can generalise it.
>
> So I'd suggest we "conditionally accept" the proposal, on the basis that
> it is amended to use modifier syntax, giving a clear signal to the
> author that the proposal isn't going to get stuck again. By
> "conditionally accept" I mean we wouldn't insist on another full round
> of committee review once the revisions are made.
>
> Also, given the delays, I think it would be best if one of us offers to
> take care of the work of revising the proposal, rather than requiring
> the author to do it (but of course asking their opinion on this proposed
> approach).
>
> Does this sound reasonable? Some of this may be what Vlad means by
> "Revise the proposal to use modifiers-based syntax and then accept", I'm
> not sure.
>
> Cheers,
>
> Adam
>
>
> On 18/12/2023 08:59, Arnaud Spiwack wrote:
> > Here's my thought.
> >
> > If the modifiers implementation arrives before #512 is implemented, then
> > it's fair to amend the proposal. If the modifiers implementation arrives
> > after #512 is implemented, then it will be time to amend the proposal,
> > add the modifier version of #512, and deprecate the pragma. If there
> > hasn't been a release of the pragma version, then it can be deleted
> > entirely. I don't really feel there needs to be additional
> > synchronisation points imposed onto contributors.
> >
> > On Thu, 14 Dec 2023 at 13:35, Richard Eisenberg <rae at richarde.dev
> > <mailto:rae at richarde.dev>> wrote:
> >
> >     Concur. Let's boldly go into the future with modifiers. :)
> >
> >     Thanks, Vlad.
> >
> >     Richard
> >
> >>     On Dec 11, 2023, at 4:31 PM, Simon Peyton Jones
> >>     <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> >>     wrote:
> >>
> >>         If we choose to revise, I volunteer to implement Modifiers in
> >>         time for GHC 9.12
> >>
> >>
> >>     Like Joachim, this changes the situation a lot.  Thank you for
> >>     offering.  You are an excellent implementor, and if you say you'll
> >>     do it, I'm sure you will.  Don't forget that, to be useful for the
> >>     author, the modifiers need to be in Template-Haskell-generated
> >>     syntax too.
> >>
> >>     With that in mind:
> >>
> >>     * [ x] Revise the proposal to use modifiers-based syntax and then
> >>     accept
> >>
> >>     I'm sure the author will be happy to use modifier syntax -- he
> >>     just needs to be sure that doing so won't block the feature and
> >>     your offer gives him that surety.
> >>
> >>     Simon
> >>
> >>     On Mon, 11 Dec 2023 at 12:40, Vladislav Zavialov
> >>     <vlad.z.4096 at gmail.com <mailto:vlad.z.4096 at gmail.com>> wrote:
> >>
> >>         Dear Committee Members,
> >>
> >>         Our previous discussion regarding #512 was inconclusive.
> >>
> >>         Thread 1:
> >>
> https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002991.html
> <
> https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002991.html
> >
> >>         Thread 2:
> >>
> https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/003015.html
> <
> https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/003015.html
> >
> >>
> >>         #512 is the proposal that introduces per-declaration,
> >>         per-constructor, and per-field NoFieldSelectors annotations.
> >>
> >>         I'm not quite sure how to summarize the discussion because
> >>         everyone seems to have a unique view. But it all revolves
> >>         around a syntactic issue: should the proposal use pragma-based
> >>         syntax or modifiers-based syntax?
> >>
> >>         Here are two facts to inform your opinion:
> >>
> >>         1. The Modifiers proposal is accepted, and it makes sense to
> >>         use it for the proposed feature
> >>         2. The Modifiers proposal is, however, unimplemented
> >>
> >>         So at the moment #512 says that we'd first introduce the
> >>         pragma-based syntax, and when Modifiers are implemented we
> >>         could deprecate the pragma-based syntax in favor of Modifiers.
> >>
> >>         I am *strongly* opposed to introducing a feature that we know
> >>         is destined for deprecation. But not everyone shares this
> >>         attitude, apparently, so let's vote.
> >>
> >>         Here are the options. Select all that you find acceptable
> >>         (multiple-choice):
> >>         * [ ] Accept the proposal with pragma-based syntax, then
> >>         deprecate it and switch to modifiers-based syntax
> >>         * [ ] Accept the proposal with pragma-based syntax, do not
> >>         switch to modifiers-based syntax
> >>         * [ ] Revise the proposal to use modifiers-based syntax and
> >>         then accept
> >>         * [ ] Reject the proposal regardless of syntax
> >>
> >>         Before you vote, let me try to sway you towards the "revise"
> >>         option. If we choose to revise, I volunteer to implement
> >>         Modifiers in time for GHC 9.12. I believe Modifiers are a
> >>         splendid idea and I envision many good uses for them.
> >>
> >>         Vlad
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240113/9f02ae2c/attachment.html>

From arnaud.spiwack at tweag.io  Mon Jan 15 08:21:01 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 15 Jan 2024 09:21:01 +0100
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <afdb3f88-cb9f-485a-9645-625d9e4107af@well-typed.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
 <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
 <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>
 <CAJKmMz9rE-bVou1XUE+5fEF_Cw8EtrbH+8RhstOZcu5OLPUSWA@mail.gmail.com>
 <010f018ccf623071-9dd56897-7356-4ca2-835f-5a4df09f963e-000000@us-east-2.amazonses.com>
 <CAJKmMz9jXWzeN6THtD1SbE9wH=aFMD4XPJyLrs_=wANioJku6A@mail.gmail.com>
 <010f018ccf6dc808-374c3c04-defd-4ca5-b5fe-13db67d8e556-000000@us-east-2.amazonses.com>
 <CAJKmMz_GbawR14jEgc5YoMXuNH_FbA5p5ps5ppQwnPAacQ70+A@mail.gmail.com>
 <afdb3f88-cb9f-485a-9645-625d9e4107af@well-typed.com>
Message-ID: <CAGwnsnn=v5dv3pjbFN2UMeOxOU6KHW789jsDJ8qhe=on=crRAA@mail.gmail.com>

On Sat, 13 Jan 2024 at 21:42, Adam Gundry <adam at well-typed.com> wrote:

> On the meta point, I agree with Simon's position here: we should avoid
> giving unconditional acceptance to underspecified proposals, only to
> potentially discover problems later. But where a proposal is not
> precisely specified, it would be preferable to accept in principle (so
> the author is not left wondering whether the idea has a chance) and then
> ask and support the author to finish the spec before merging the PR.


I agree too. I was thinking about it over the weekend: we kind of need a
status to say “we pretty much know we're going to accept it, so go ahead
and do the implementation, but we're still working the details out
together” (I was thinking in particular of the choice of string delimiters
from this proposal: it makes no material difference to the implementation
what we eventually settle on. So if there are questions, we should avoid
holding the implementation effort back just because we're having a
discussion about what we think it best).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240115/ac7457f1/attachment.html>

From arnaud.spiwack at tweag.io  Mon Jan 15 08:51:49 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 15 Jan 2024 09:51:49 +0100
Subject: [ghc-steering-committee] #626: Amendment of Visible Forall in
 Types, recommendation: Accept
In-Reply-To: <CAGwnsnkVMdTykbuFd9+ujaN1yz4My_MsC_Aiwu46anEzXNetBg@mail.gmail.com>
References: <CAGwnsnkpCa2NMPBPDd_hEA=vHQLbMzvtr78+EJsYQDa5Qcu+DQ@mail.gmail.com>
 <CAJKmMz9+-xpr-X5V+4A=1Ctuvs9Xd+5oW8UgzRbZ8d=sQqU_tQ@mail.gmail.com>
 <CAGwnsnkM7FPRAXeTik5g2Na3s+Dzv2ifAhkzpukydaQ8Hz0NTQ@mail.gmail.com>
 <010f018cca3e8920-cd21c435-0d3e-4c0b-8ba1-e4319539ed5d-000000@us-east-2.amazonses.com>
 <CAGwnsnmgqk8qzueATWiWg4_81Av2c1S+tyRaECxn5iWFZV674Q@mail.gmail.com>
 <010f018cfb43a06a-c6cd0a9d-9100-4de6-94d4-63a211d9e75b-000000@us-east-2.amazonses.com>
 <CAGwnsnkVMdTykbuFd9+ujaN1yz4My_MsC_Aiwu46anEzXNetBg@mail.gmail.com>
Message-ID: <CAGwnsnnn8F+jAu=6aVFv7BhBgs96Lhevhy2=X+136BdN48MXgw@mail.gmail.com>

Alright, no further opinions. I'll interpret, as is the custom, silence as
assent, and mark this proposal as accepted.

On Fri, 12 Jan 2024 at 11:12, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> I actually hadn't noticed, thanks Richard. For the record: said change
> removes the icky ambiguity on `p -> q`, which is always parsed as a view
> pattern.
>
>
> On Fri, 12 Jan 2024 at 02:22, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> (For what it's worth, my suggestion was accepted and has been
>> incorporated into the proposal.)
>>
>> On Jan 9, 2024, at 10:43 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> Any other thoughts? If not, I'll consider this proposal accepted at the
>> end of this week.
>>
>> On Tue, 2 Jan 2024 at 13:55, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>>> I support the amendment. I made one small suggestion, but I wish to vote
>>> for acceptance regardless of the status of this suggestion.
>>>
>>> Richard
>>>
>>> On Dec 22, 2023, at 9:20 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>> I realised today that we haven't completed the vote on this. This is
>>> really a very simple proposal, let's not spend too long on this. I'll be on
>>> holiday for the next two weeks, I'm a bit embarrassed to send this email
>>> only now. But please opine soon. I'd like to be able to give an answer soon
>>> after I'm back (say on the 12th January)
>>>
>>> Best,
>>> Arnaud
>>>
>>> On Mon, 11 Dec 2023 at 11:06, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> I recommend acceptance too.  It's all very fine detail.
>>>>
>>>> The actual diff seems quite large but that's because I encouraged Vlad
>>>> to take the opportunity to clarity the rather cryptic sentence in the
>>>> original #218, namely "The syntactic descriptions here applying to
>>>> expressions apply equally to patterns, though we will continue to discuss
>>>> only expressions."  Instead it is all spelled out much more explicitly,
>>>> which is way better.  Indeed spelling it out showed up a dark corner to do
>>>> with view patterns, hence the icky stuff Arnaud mentions.
>>>>
>>>> Simon
>>>>
>>>>    -
>>>>
>>>>
>>>> On Mon, 11 Dec 2023 at 09:56, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>>> wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> Vlad is proposing to amend his own proposal
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/626
>>>>>
>>>>> Being an amendment, it's, as always, not as straightforward to
>>>>> consume, but Vlad gives us a good summary of the changes in his
>>>>> pull-request description.
>>>>>
>>>>> All in all, it's almost entirely straightforward clarification. There
>>>>> are two items of notice: patterns for visible forall arguments were
>>>>> specified as: only variable or wildcard. The amendment changes it to allow
>>>>> data constructors applied to (0 or more) patterns as well. The amended
>>>>> version is consistent with how patterns for invisible forall arguments are
>>>>> specified. The second, and this one is for Moritz, is a small change in the
>>>>> parsing of view patterns (it does break two packages at least on Hackage,
>>>>> but I actually don't quite understand how the change can affect semantics.
>>>>> It's that tiny. Vlad proposes 3 releases with warning before effecting the
>>>>> change).
>>>>>
>>>>> Maybe there's a third item: `p -> q` parses differently depending on
>>>>> whether ViewPattern or RequiredTypeArguments (or both) is turned on. This
>>>>> is kind of icky, I suppose. But in the case where both are on, then
>>>>> ViewPattern wins, so there's no real harm in it.
>>>>>
>>>>> Do pay some attention to the new items in the alternatives section.
>>>>>
>>>>> Anyway, I recommend we accept.
>>>>>
>>>>> --
>>>>> Arnaud Spiwack
>>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>>
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>>
>>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
>>
>>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240115/d2795941/attachment.html>

From arnaud.spiwack at tweag.io  Mon Jan 15 15:00:51 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 15 Jan 2024 16:00:51 +0100
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <b4dad401-e7fd-42e4-ba41-6b5247646e42@well-typed.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <b4dad401-e7fd-42e4-ba41-6b5247646e42@well-typed.com>
Message-ID: <CAGwnsn=1hVA=09XbVXDKUxXJ8UbA6ssUgq=xrTGx_XEVZ1borQ@mail.gmail.com>

What's simplest is not obvious.

- Only accepting concrete `!pat` if there's a %p gives simpler error
messages, but is a few lines of code extra (and you may end up with lets
that are inferred linear but you can't add `let %1` on them if the
inference algorithm uses a more clever definition of strict)
- Considering a pattern as strict when `-XStrict` or in brackets, is a few
extra lines of code but maybe more intuitive.

In any case, I consider all these choices to be quite comparable in
simplicity from a code perspective (and for the record, the least amount of
work for me is to use both alternatives, because they're the version that
I've already implemented). What does the user consider simplest?

On Sat, 13 Jan 2024 at 21:00, Adam Gundry <adam at well-typed.com> wrote:

> I haven't looked at this closely, but I'm happy to trust Arnaud and
> Richard's judgment and accept, especially since LinearTypes is at a very
> experimental stage.
>
> Adam
>
>
> On 12/01/2024 10:08, Arnaud Spiwack wrote:
> > At Richard's prompting, I've added the following alternative to the
> > proposal (the current proposal is the most conservative of the two,
> > which we can choose to stick to if we're unsure). I'm copying the
> > alternative here because rendering seems to be broken on Github right
> now.
> >
> > I'm rather agnostic on which side we choose, to be honest. Anyone with
> > medium-to-strong opinions on the question?
> >
> >
> > Restrictions of multiplicity-annotated let bindings
> > ---------------------------------------------------
> >
> > The proposal specifies that a multiplicity annotated non-variable let
> > binding ``let %p pat``
> > must be such that ``pat = !pat'`` even if ``p = 'Many``. It is easy to
> > lift this restriction on two dimension:
> >
> > - We can say, instead, that patterns not of the form ``!pat'`` emit a
> >    ``p ~ 'Many`` constraint instead. They already do (for the sake of
> >    inference), so this is strictly less code.
> > - We can generalise to more strict patterns. For instance, we don't
> >    need to require a ``!`` if ``-XStrict`` is on, we can have patterns
> >    of the form ``(!pat')`` (with additional parentheses). This is a few
> >    lines of codes, inference actually already does this in my
> >    implementation, so it's already paid for (though it does annoyingly
> >    mostly duplicate another definition of strict pattern which I
> >    couldn't find a way to factor as a single function, I don't like
> >    this).
> >
> > The reason that motivated the stronger restriction is to improve error
> > messages, because we can then error out with “multiplicity-annotated
> > let-bound patterns must be of the form !pat”, instead of the more
> > mysterious “Couldn't unify 'Many with 'One”
> > (see `#23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586
> > <https://gitlab.haskell.org/ghc/ghc/-/issues/23586>>`_).
> > But maybe the additional restrictions are more surprising than the
> > error messages are helpful.
> >
> > On Mon, 8 Jan 2024 at 10:07, Simon Peyton Jones
> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> wrote:
> >
> >     I support acceptance.  Let's land this soon.
> >
> >     Simon
> >
> >     On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev
> >     <mailto:rae at richarde.dev>> wrote:
> >
> >         Hi all,
> >
> >         I've reviewed Arnaud's
> >         https://github.com/ghc-proposals/ghc-proposals/pull/624
> >         <https://github.com/ghc-proposals/ghc-proposals/pull/624> and
> >         wish to recommend acceptance.
> >
> >         The proposal is an amendment to the proposal for linear types,
> >         adding support for linear let bindings.
> >
> >         Today, if you have
> >
> >         f :: T %1-> T
> >         f t = let t2 = t in t2
> >
> >         you'll get an error because t2 is not linear. The only way to
> >         bind a linear variable is via a `case`, never a `let` or
> >         `where`. This is annoying. With this proposal, the little
> >         program above is accepted, with an inferred linearity
> >         restriction on t2. Users can also annotated their lets like `let
> >         %1 x = ... in ...`. Bindings in `where` clauses can also be
> >         inferred or annotated as linear.
> >
> >         There is a downside, of course: linear bindings have various
> >         restrictions, chiefly that they must be strict bindings (because
> >         projections are hard with linear types) and that bindings cannot
> >         be generalized. I'm a little unsure that the choices in the
> >         proposal (particularly around generalization) are the best for
> >         users, but I think the best way to learn is to experiment. In my
> >         understanding, the community knows that -XLinearTypes is subject
> >         to revision, and so I think we should just blast ahead, revising
> >         if and when necessary.
> >
> >         Please share your thoughts!
> >
> >         Thanks,
> >         Richard
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240115/28499b93/attachment.html>

From simon.peytonjones at gmail.com  Tue Jan 16 09:58:55 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 16 Jan 2024 09:58:55 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAGwnsn=1hVA=09XbVXDKUxXJ8UbA6ssUgq=xrTGx_XEVZ1borQ@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <b4dad401-e7fd-42e4-ba41-6b5247646e42@well-typed.com>
 <CAGwnsn=1hVA=09XbVXDKUxXJ8UbA6ssUgq=xrTGx_XEVZ1borQ@mail.gmail.com>
Message-ID: <CAJKmMz9XqQKGFN3EG50ufpTEgk2p=8Xewto_KhsZk9fjeFiGpw@mail.gmail.com>

Arnaud, I'm sorry but I'm not close enough to this proposal to understand
the alternatives.


   - I think that the issue you are debating only arises when you, the
   programmer, want to *explicitly annotate *a let/where binding with a
   multiplicity.  Right?
   - I think that you are saying that all bindings with a *non-Many
*multiplicity
   *must *be strict.
   - I think the choices you are identifying are:
      - If the explicit annotation is Many, does the binding still need to
      be strict?
      - If the binding needs to be strict, do we insist on an explicit !
      or, if -XStrict is on can we omit that bang?

Are those the choices you are putting before us?  It would help just to lay
it out soe that even people who aren't close to linear types can have a
chance to contribute.  Otherwise we'll end up with silence, which is not
helpful to you.

Perhaps also this debate can be on the GitHub thread, rather than the
mailing list.

Simon

On Mon, 15 Jan 2024 at 15:01, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> What's simplest is not obvious.
>
> - Only accepting concrete `!pat` if there's a %p gives simpler error
> messages, but is a few lines of code extra (and you may end up with lets
> that are inferred linear but you can't add `let %1` on them if the
> inference algorithm uses a more clever definition of strict)
> - Considering a pattern as strict when `-XStrict` or in brackets, is a few
> extra lines of code but maybe more intuitive.
>
> In any case, I consider all these choices to be quite comparable in
> simplicity from a code perspective (and for the record, the least amount of
> work for me is to use both alternatives, because they're the version that
> I've already implemented). What does the user consider simplest?
>
> On Sat, 13 Jan 2024 at 21:00, Adam Gundry <adam at well-typed.com> wrote:
>
>> I haven't looked at this closely, but I'm happy to trust Arnaud and
>> Richard's judgment and accept, especially since LinearTypes is at a very
>> experimental stage.
>>
>> Adam
>>
>>
>> On 12/01/2024 10:08, Arnaud Spiwack wrote:
>> > At Richard's prompting, I've added the following alternative to the
>> > proposal (the current proposal is the most conservative of the two,
>> > which we can choose to stick to if we're unsure). I'm copying the
>> > alternative here because rendering seems to be broken on Github right
>> now.
>> >
>> > I'm rather agnostic on which side we choose, to be honest. Anyone with
>> > medium-to-strong opinions on the question?
>> >
>> >
>> > Restrictions of multiplicity-annotated let bindings
>> > ---------------------------------------------------
>> >
>> > The proposal specifies that a multiplicity annotated non-variable let
>> > binding ``let %p pat``
>> > must be such that ``pat = !pat'`` even if ``p = 'Many``. It is easy to
>> > lift this restriction on two dimension:
>> >
>> > - We can say, instead, that patterns not of the form ``!pat'`` emit a
>> >    ``p ~ 'Many`` constraint instead. They already do (for the sake of
>> >    inference), so this is strictly less code.
>> > - We can generalise to more strict patterns. For instance, we don't
>> >    need to require a ``!`` if ``-XStrict`` is on, we can have patterns
>> >    of the form ``(!pat')`` (with additional parentheses). This is a few
>> >    lines of codes, inference actually already does this in my
>> >    implementation, so it's already paid for (though it does annoyingly
>> >    mostly duplicate another definition of strict pattern which I
>> >    couldn't find a way to factor as a single function, I don't like
>> >    this).
>> >
>> > The reason that motivated the stronger restriction is to improve error
>> > messages, because we can then error out with “multiplicity-annotated
>> > let-bound patterns must be of the form !pat”, instead of the more
>> > mysterious “Couldn't unify 'Many with 'One”
>> > (see `#23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586
>> > <https://gitlab.haskell.org/ghc/ghc/-/issues/23586>>`_).
>> > But maybe the additional restrictions are more surprising than the
>> > error messages are helpful.
>> >
>> > On Mon, 8 Jan 2024 at 10:07, Simon Peyton Jones
>> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>> wrote:
>> >
>> >     I support acceptance.  Let's land this soon.
>> >
>> >     Simon
>> >
>> >     On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev
>> >     <mailto:rae at richarde.dev>> wrote:
>> >
>> >         Hi all,
>> >
>> >         I've reviewed Arnaud's
>> >         https://github.com/ghc-proposals/ghc-proposals/pull/624
>> >         <https://github.com/ghc-proposals/ghc-proposals/pull/624> and
>> >         wish to recommend acceptance.
>> >
>> >         The proposal is an amendment to the proposal for linear types,
>> >         adding support for linear let bindings.
>> >
>> >         Today, if you have
>> >
>> >         f :: T %1-> T
>> >         f t = let t2 = t in t2
>> >
>> >         you'll get an error because t2 is not linear. The only way to
>> >         bind a linear variable is via a `case`, never a `let` or
>> >         `where`. This is annoying. With this proposal, the little
>> >         program above is accepted, with an inferred linearity
>> >         restriction on t2. Users can also annotated their lets like `let
>> >         %1 x = ... in ...`. Bindings in `where` clauses can also be
>> >         inferred or annotated as linear.
>> >
>> >         There is a downside, of course: linear bindings have various
>> >         restrictions, chiefly that they must be strict bindings (because
>> >         projections are hard with linear types) and that bindings cannot
>> >         be generalized. I'm a little unsure that the choices in the
>> >         proposal (particularly around generalization) are the best for
>> >         users, but I think the best way to learn is to experiment. In my
>> >         understanding, the community knows that -XLinearTypes is subject
>> >         to revision, and so I think we should just blast ahead, revising
>> >         if and when necessary.
>> >
>> >         Please share your thoughts!
>> >
>> >         Thanks,
>> >         Richard
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240116/936f8803/attachment-0001.html>

From rae at richarde.dev  Tue Jan 16 18:52:25 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 16 Jan 2024 18:52:25 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
Message-ID: <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>

I say we have our cake and eat it, too: get better inference and better error messages. I think this shouldn't be all that hard: when emitting the constraint that the linearity of the binding is `Many`, use an appropriate `CtOrigin` that can render as an informative message. I haven't gone through the code to see exactly the best structure here, but I feel pretty confident that this should be straightforward.

So I'm for the design Arnaud articulates below, but support the proposal regardless.

Richard

> On Jan 12, 2024, at 3:08 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> At Richard's prompting, I've added the following alternative to the proposal (the current proposal is the most conservative of the two, which we can choose to stick to if we're unsure). I'm copying the alternative here because rendering seems to be broken on Github right now.
> 
> I'm rather agnostic on which side we choose, to be honest. Anyone with medium-to-strong opinions on the question?
> 
> 
> Restrictions of multiplicity-annotated let bindings
> ---------------------------------------------------
> 
> The proposal specifies that a multiplicity annotated non-variable let binding ``let %p pat``
> must be such that ``pat = !pat'`` even if ``p = 'Many``. It is easy to
> lift this restriction on two dimension:
> 
> - We can say, instead, that patterns not of the form ``!pat'`` emit a
>   ``p ~ 'Many`` constraint instead. They already do (for the sake of
>   inference), so this is strictly less code.
> - We can generalise to more strict patterns. For instance, we don't
>   need to require a ``!`` if ``-XStrict`` is on, we can have patterns
>   of the form ``(!pat')`` (with additional parentheses). This is a few
>   lines of codes, inference actually already does this in my
>   implementation, so it's already paid for (though it does annoyingly
>   mostly duplicate another definition of strict pattern which I
>   couldn't find a way to factor as a single function, I don't like
>   this).
> 
> The reason that motivated the stronger restriction is to improve error
> messages, because we can then error out with “multiplicity-annotated
> let-bound patterns must be of the form !pat”, instead of the more
> mysterious “Couldn't unify 'Many with 'One”
> (see `#23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586>>`_).
> But maybe the additional restrictions are more surprising than the
> error messages are helpful.
> 
> On Mon, 8 Jan 2024 at 10:07, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> I support acceptance.  Let's land this soon.
> 
> Simon
> 
> On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> Hi all,
> 
> I've reviewed Arnaud's https://github.com/ghc-proposals/ghc-proposals/pull/624 <https://github.com/ghc-proposals/ghc-proposals/pull/624> and wish to recommend acceptance.
> 
> The proposal is an amendment to the proposal for linear types, adding support for linear let bindings.
> 
> Today, if you have
> 
> f :: T %1-> T
> f t = let t2 = t in t2
> 
> you'll get an error because t2 is not linear. The only way to bind a linear variable is via a `case`, never a `let` or `where`. This is annoying. With this proposal, the little program above is accepted, with an inferred linearity restriction on t2. Users can also annotated their lets like `let %1 x = ... in ...`. Bindings in `where` clauses can also be inferred or annotated as linear.
> 
> There is a downside, of course: linear bindings have various restrictions, chiefly that they must be strict bindings (because projections are hard with linear types) and that bindings cannot be generalized. I'm a little unsure that the choices in the proposal (particularly around generalization) are the best for users, but I think the best way to learn is to experiment. In my understanding, the community knows that -XLinearTypes is subject to revision, and so I think we should just blast ahead, revising if and when necessary.
> 
> Please share your thoughts!
> 
> Thanks,
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240116/39ccca7f/attachment.html>

From simon.peytonjones at gmail.com  Tue Jan 16 19:52:15 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 16 Jan 2024 19:52:15 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>

Richard

Arnaud articulates some alternatives, which I am very fuzzy about (as I say
in my email).

Can you say which alternative you support?   (I'm thinking of the language
design only; I'm sure we can implement whichever design we choose.)

Simon

On Tue, 16 Jan 2024 at 18:52, Richard Eisenberg <rae at richarde.dev> wrote:

> I say we have our cake and eat it, too: get better inference and better
> error messages. I think this shouldn't be all that hard: when emitting the
> constraint that the linearity of the binding is `Many`, use an appropriate
> `CtOrigin` that can render as an informative message. I haven't gone
> through the code to see exactly the best structure here, but I feel pretty
> confident that this should be straightforward.
>
> So I'm for the design Arnaud articulates below, but support the proposal
> regardless.
>
> Richard
>
> On Jan 12, 2024, at 3:08 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
> At Richard's prompting, I've added the following alternative to the
> proposal (the current proposal is the most conservative of the two, which
> we can choose to stick to if we're unsure). I'm copying the alternative
> here because rendering seems to be broken on Github right now.
>
> I'm rather agnostic on which side we choose, to be honest. Anyone with
> medium-to-strong opinions on the question?
>
>
> Restrictions of multiplicity-annotated let bindings
> ---------------------------------------------------
>
> The proposal specifies that a multiplicity annotated non-variable let
> binding ``let %p pat``
> must be such that ``pat = !pat'`` even if ``p = 'Many``. It is easy to
> lift this restriction on two dimension:
>
> - We can say, instead, that patterns not of the form ``!pat'`` emit a
>   ``p ~ 'Many`` constraint instead. They already do (for the sake of
>   inference), so this is strictly less code.
> - We can generalise to more strict patterns. For instance, we don't
>   need to require a ``!`` if ``-XStrict`` is on, we can have patterns
>   of the form ``(!pat')`` (with additional parentheses). This is a few
>   lines of codes, inference actually already does this in my
>   implementation, so it's already paid for (though it does annoyingly
>   mostly duplicate another definition of strict pattern which I
>   couldn't find a way to factor as a single function, I don't like
>   this).
>
> The reason that motivated the stronger restriction is to improve error
> messages, because we can then error out with “multiplicity-annotated
> let-bound patterns must be of the form !pat”, instead of the more
> mysterious “Couldn't unify 'Many with 'One”
> (see `#23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586>`_).
> But maybe the additional restrictions are more surprising than the
> error messages are helpful.
>
> On Mon, 8 Jan 2024 at 10:07, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I support acceptance.  Let's land this soon.
>>
>> Simon
>>
>> On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>>> Hi all,
>>>
>>> I've reviewed Arnaud's
>>> https://github.com/ghc-proposals/ghc-proposals/pull/624 and wish to
>>> recommend acceptance.
>>>
>>> The proposal is an amendment to the proposal for linear types, adding
>>> support for linear let bindings.
>>>
>>> Today, if you have
>>>
>>> f :: T %1-> T
>>> f t = let t2 = t in t2
>>>
>>> you'll get an error because t2 is not linear. The only way to bind a
>>> linear variable is via a `case`, never a `let` or `where`. This is
>>> annoying. With this proposal, the little program above is accepted, with an
>>> inferred linearity restriction on t2. Users can also annotated their lets
>>> like `let %1 x = ... in ...`. Bindings in `where` clauses can also be
>>> inferred or annotated as linear.
>>>
>>> There is a downside, of course: linear bindings have various
>>> restrictions, chiefly that they must be strict bindings (because
>>> projections are hard with linear types) and that bindings cannot be
>>> generalized. I'm a little unsure that the choices in the proposal
>>> (particularly around generalization) are the best for users, but I think
>>> the best way to learn is to experiment. In my understanding, the community
>>> knows that -XLinearTypes is subject to revision, and so I think we should
>>> just blast ahead, revising if and when necessary.
>>>
>>> Please share your thoughts!
>>>
>>> Thanks,
>>> Richard
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240116/cff02080/attachment-0001.html>

From adam at well-typed.com  Wed Jan 17 09:08:19 2024
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 17 Jan 2024 09:08:19 +0000
Subject: [ghc-steering-committee] Secretary of the GHC Steering Committee
In-Reply-To: <CAJKmMz9d+JncAP8A2VGTwSC8dXuJ1G7hnkqOa7090a+j_xhN-A@mail.gmail.com>
References: <CAJKmMz9d+JncAP8A2VGTwSC8dXuJ1G7hnkqOa7090a+j_xhN-A@mail.gmail.com>
Message-ID: <5d5b963d-2d81-433d-b07a-747539fcc487@well-typed.com>

Yes, many thanks to Joachim for all your work over the years as secretary!

As Simon mentioned, I'm in principle willing to take on the role, if the 
committee is agreeable. Please do confirm if you're happy with this, or 
say if you'd like to volunteer yourself or propose a different course of 
action.

Cheers,

Adam


On 11/01/2024 09:00, Simon Peyton Jones wrote:
> Dear GHC Steering Committee
> 
> Joachim's term of membership in the GHC SC comes to an end in March, and 
> he wants to stand down as our Secretary.
> 
> Joachim, you have done a fantastic job as our secretary, nudging us with 
> regular status updates, making sure we hold membership nomination 
> processes, and much more besides.  You have made sure that we function 
> well as a committee, and I for one have leaned heavily on your support. 
> Thank you so much.
> 
> Would anyone else like to be Secretary?  I am delighted to say that Adam 
> is willing to serve, but if anyone else would like to join in or share 
> the role, that would be great too.   Thank you Adam!
> 
> RSVP!
> 
> Thanks again Joachim.
> 
> Simon

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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From moritz.angermann at gmail.com  Wed Jan 17 09:47:56 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 17 Jan 2024 17:47:56 +0800
Subject: [ghc-steering-committee] Secretary of the GHC Steering Committee
In-Reply-To: <5d5b963d-2d81-433d-b07a-747539fcc487@well-typed.com>
References: <CAJKmMz9d+JncAP8A2VGTwSC8dXuJ1G7hnkqOa7090a+j_xhN-A@mail.gmail.com>
 <5d5b963d-2d81-433d-b07a-747539fcc487@well-typed.com>
Message-ID: <CAKfdd-w8D3GLdunOEAUQ=99pP10jOoWFTBV=w5zVODQnCcw99A@mail.gmail.com>

I’m agreeable! Thank you for stepping up Adam!

On Wed, 17 Jan 2024 at 5:08 PM, Adam Gundry <adam at well-typed.com> wrote:

> Yes, many thanks to Joachim for all your work over the years as secretary!
>
> As Simon mentioned, I'm in principle willing to take on the role, if the
> committee is agreeable. Please do confirm if you're happy with this, or
> say if you'd like to volunteer yourself or propose a different course of
> action.
>
> Cheers,
>
> Adam
>
>
> On 11/01/2024 09:00, Simon Peyton Jones wrote:
> > Dear GHC Steering Committee
> >
> > Joachim's term of membership in the GHC SC comes to an end in March, and
> > he wants to stand down as our Secretary.
> >
> > Joachim, you have done a fantastic job as our secretary, nudging us with
> > regular status updates, making sure we hold membership nomination
> > processes, and much more besides.  You have made sure that we function
> > well as a committee, and I for one have leaned heavily on your support.
> > Thank you so much.
> >
> > Would anyone else like to be Secretary?  I am delighted to say that Adam
> > is willing to serve, but if anyone else would like to join in or share
> > the role, that would be great too.   Thank you Adam!
> >
> > RSVP!
> >
> > Thanks again Joachim.
> >
> > Simon
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240117/e1b77607/attachment.html>

From rae at richarde.dev  Wed Jan 17 21:30:03 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 17 Jan 2024 21:30:03 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
Message-ID: <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>

Sorry for being vague: I support emitting the constraint equating the linearity annotation to `Many` whenever the binding is of a form that linearity can't handle, with a CtOrigin that makes for a good error message.

I also support allowing bang-less patterns to be linear with -XStrict; my understanding of the specification of -XStrict is that it should mean "put bangs everywhere", so accepting bang-less patterns as linear here sounds right. My hope is that this is actually a simplification, because I would imagine there some notion of "strict binding" -- encompassing both a binding with an outer ! and any binding with -XStrict -- and then this new feature just hooks into that one.

Richard

> On Jan 16, 2024, at 12:52 PM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Richard
> 
> Arnaud articulates some alternatives, which I am very fuzzy about (as I say in my email).
> 
> Can you say which alternative you support?   (I'm thinking of the language design only; I'm sure we can implement whichever design we choose.)
> 
> Simon
> 
> On Tue, 16 Jan 2024 at 18:52, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> I say we have our cake and eat it, too: get better inference and better error messages. I think this shouldn't be all that hard: when emitting the constraint that the linearity of the binding is `Many`, use an appropriate `CtOrigin` that can render as an informative message. I haven't gone through the code to see exactly the best structure here, but I feel pretty confident that this should be straightforward.
> 
> So I'm for the design Arnaud articulates below, but support the proposal regardless.
> 
> Richard
> 
>> On Jan 12, 2024, at 3:08 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>> 
>> At Richard's prompting, I've added the following alternative to the proposal (the current proposal is the most conservative of the two, which we can choose to stick to if we're unsure). I'm copying the alternative here because rendering seems to be broken on Github right now.
>> 
>> I'm rather agnostic on which side we choose, to be honest. Anyone with medium-to-strong opinions on the question?
>> 
>> 
>> Restrictions of multiplicity-annotated let bindings
>> ---------------------------------------------------
>> 
>> The proposal specifies that a multiplicity annotated non-variable let binding ``let %p pat``
>> must be such that ``pat = !pat'`` even if ``p = 'Many``. It is easy to
>> lift this restriction on two dimension:
>> 
>> - We can say, instead, that patterns not of the form ``!pat'`` emit a
>>   ``p ~ 'Many`` constraint instead. They already do (for the sake of
>>   inference), so this is strictly less code.
>> - We can generalise to more strict patterns. For instance, we don't
>>   need to require a ``!`` if ``-XStrict`` is on, we can have patterns
>>   of the form ``(!pat')`` (with additional parentheses). This is a few
>>   lines of codes, inference actually already does this in my
>>   implementation, so it's already paid for (though it does annoyingly
>>   mostly duplicate another definition of strict pattern which I
>>   couldn't find a way to factor as a single function, I don't like
>>   this).
>> 
>> The reason that motivated the stronger restriction is to improve error
>> messages, because we can then error out with “multiplicity-annotated
>> let-bound patterns must be of the form !pat”, instead of the more
>> mysterious “Couldn't unify 'Many with 'One”
>> (see `#23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586>>`_).
>> But maybe the additional restrictions are more surprising than the
>> error messages are helpful.
>> 
>> On Mon, 8 Jan 2024 at 10:07, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> I support acceptance.  Let's land this soon.
>> 
>> Simon
>> 
>> On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>> Hi all,
>> 
>> I've reviewed Arnaud's https://github.com/ghc-proposals/ghc-proposals/pull/624 <https://github.com/ghc-proposals/ghc-proposals/pull/624> and wish to recommend acceptance.
>> 
>> The proposal is an amendment to the proposal for linear types, adding support for linear let bindings.
>> 
>> Today, if you have
>> 
>> f :: T %1-> T
>> f t = let t2 = t in t2
>> 
>> you'll get an error because t2 is not linear. The only way to bind a linear variable is via a `case`, never a `let` or `where`. This is annoying. With this proposal, the little program above is accepted, with an inferred linearity restriction on t2. Users can also annotated their lets like `let %1 x = ... in ...`. Bindings in `where` clauses can also be inferred or annotated as linear.
>> 
>> There is a downside, of course: linear bindings have various restrictions, chiefly that they must be strict bindings (because projections are hard with linear types) and that bindings cannot be generalized. I'm a little unsure that the choices in the proposal (particularly around generalization) are the best for users, but I think the best way to learn is to experiment. In my understanding, the community knows that -XLinearTypes is subject to revision, and so I think we should just blast ahead, revising if and when necessary.
>> 
>> Please share your thoughts!
>> 
>> Thanks,
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> 
>> 
>> -- 
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240117/9ce91078/attachment.html>

From simon.peytonjones at gmail.com  Thu Jan 18 11:12:14 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 18 Jan 2024 11:12:14 +0000
Subject: [ghc-steering-committee] Secretary of the GHC Steering Committee
In-Reply-To: <CAJKmMz9d+JncAP8A2VGTwSC8dXuJ1G7hnkqOa7090a+j_xhN-A@mail.gmail.com>
References: <CAJKmMz9d+JncAP8A2VGTwSC8dXuJ1G7hnkqOa7090a+j_xhN-A@mail.gmail.com>
Message-ID: <CAJKmMz9rRHGfYnFrCa6MokQaTYZ1UNA5AXH3CFTKuwqqwEeGag@mail.gmail.com>

Dear GHC Steering Committee

I got one reply (from Moritz) to my email below.  I hope that the rest of
you received it.

That means that no one else is putting themselves forward to be Secretary.  *So
I declare that Adam is duly appointed as Secretary to our committee*.
Thank you Adam!

And renewed thanks to Joachim for being such a great Secretary.

Simon

On Thu, 11 Jan 2024 at 09:00, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC Steering Committee
>
> Joachim's term of membership in the GHC SC comes to an end in March, and
> he wants to stand down as our Secretary.
>
> Joachim, you have done a fantastic job as our secretary, nudging us with
> regular status updates, making sure we hold membership nomination
> processes, and much more besides.  You have made sure that we function well
> as a committee, and I for one have leaned heavily on your support.  Thank
> you so much.
>
> Would anyone else like to be Secretary?  I am delighted to say that Adam
> is willing to serve, but if anyone else would like to join in or share the
> role, that would be great too.   Thank you Adam!
>
> RSVP!
>
> Thanks again Joachim.
>
> Simon
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240118/6a3a68d4/attachment.html>

From moritz.angermann at gmail.com  Thu Jan 18 11:35:44 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 18 Jan 2024 19:35:44 +0800
Subject: [ghc-steering-committee] Secretary of the GHC Steering Committee
In-Reply-To: <CAJKmMz9rRHGfYnFrCa6MokQaTYZ1UNA5AXH3CFTKuwqqwEeGag@mail.gmail.com>
References: <CAJKmMz9d+JncAP8A2VGTwSC8dXuJ1G7hnkqOa7090a+j_xhN-A@mail.gmail.com>
 <CAJKmMz9rRHGfYnFrCa6MokQaTYZ1UNA5AXH3CFTKuwqqwEeGag@mail.gmail.com>
Message-ID: <CAKfdd-zMYiqnje8sdnxh_j-EFX9qvuAJpuOFohfX6pK8v5qV_Q@mail.gmail.com>

Thank you Joachim! Thank you Adam! Thank you Simon!

On Thu, 18 Jan 2024 at 7:12 PM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC Steering Committee
>
> I got one reply (from Moritz) to my email below.  I hope that the rest of
> you received it.
>
> That means that no one else is putting themselves forward to be
> Secretary.  *So I declare that Adam is duly appointed as Secretary to our
> committee*.   Thank you Adam!
>
> And renewed thanks to Joachim for being such a great Secretary.
>
>
> Simon
>
> On Thu, 11 Jan 2024 at 09:00, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear GHC Steering Committee
>>
>> Joachim's term of membership in the GHC SC comes to an end in March, and
>> he wants to stand down as our Secretary.
>>
>> Joachim, you have done a fantastic job as our secretary, nudging us with
>> regular status updates, making sure we hold membership nomination
>> processes, and much more besides.  You have made sure that we function well
>> as a committee, and I for one have leaned heavily on your support.  Thank
>> you so much.
>>
>> Would anyone else like to be Secretary?  I am delighted to say that Adam
>> is willing to serve, but if anyone else would like to join in or share the
>> role, that would be great too.   Thank you Adam!
>>
>> RSVP!
>>
>> Thanks again Joachim.
>>
>> Simon
>>
>>
>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240118/e3eb2583/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Jan 19 10:42:18 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 19 Jan 2024 11:42:18 +0100
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
Message-ID: <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>

Richard seems to be the only one with a strong opinion on this. I'm happy
to implement Richard's recommendations (both in the proposal and in the
code), unless there are dissenting voices?

On Wed, 17 Jan 2024 at 22:30, Richard Eisenberg <rae at richarde.dev> wrote:

> Sorry for being vague: I support emitting the constraint equating the
> linearity annotation to `Many` whenever the binding is of a form that
> linearity can't handle, with a CtOrigin that makes for a good error message.
>
> I also support allowing bang-less patterns to be linear with -XStrict; my
> understanding of the specification of -XStrict is that it should mean "put
> bangs everywhere", so accepting bang-less patterns as linear here sounds
> right. My hope is that this is actually a simplification, because I would
> imagine there some notion of "strict binding" -- encompassing both a
> binding with an outer ! and any binding with -XStrict -- and then this new
> feature just hooks into that one.
>
> Richard
>
> On Jan 16, 2024, at 12:52 PM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
> Richard
>
> Arnaud articulates some alternatives, which I am very fuzzy about (as I
> say in my email).
>
> Can you say which alternative you support?   (I'm thinking of the language
> design only; I'm sure we can implement whichever design we choose.)
>
> Simon
>
> On Tue, 16 Jan 2024 at 18:52, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> I say we have our cake and eat it, too: get better inference and better
>> error messages. I think this shouldn't be all that hard: when emitting the
>> constraint that the linearity of the binding is `Many`, use an appropriate
>> `CtOrigin` that can render as an informative message. I haven't gone
>> through the code to see exactly the best structure here, but I feel pretty
>> confident that this should be straightforward.
>>
>> So I'm for the design Arnaud articulates below, but support the proposal
>> regardless.
>>
>> Richard
>>
>> On Jan 12, 2024, at 3:08 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> At Richard's prompting, I've added the following alternative to the
>> proposal (the current proposal is the most conservative of the two, which
>> we can choose to stick to if we're unsure). I'm copying the alternative
>> here because rendering seems to be broken on Github right now.
>>
>> I'm rather agnostic on which side we choose, to be honest. Anyone with
>> medium-to-strong opinions on the question?
>>
>>
>> Restrictions of multiplicity-annotated let bindings
>> ---------------------------------------------------
>>
>> The proposal specifies that a multiplicity annotated non-variable let
>> binding ``let %p pat``
>> must be such that ``pat = !pat'`` even if ``p = 'Many``. It is easy to
>> lift this restriction on two dimension:
>>
>> - We can say, instead, that patterns not of the form ``!pat'`` emit a
>>   ``p ~ 'Many`` constraint instead. They already do (for the sake of
>>   inference), so this is strictly less code.
>> - We can generalise to more strict patterns. For instance, we don't
>>   need to require a ``!`` if ``-XStrict`` is on, we can have patterns
>>   of the form ``(!pat')`` (with additional parentheses). This is a few
>>   lines of codes, inference actually already does this in my
>>   implementation, so it's already paid for (though it does annoyingly
>>   mostly duplicate another definition of strict pattern which I
>>   couldn't find a way to factor as a single function, I don't like
>>   this).
>>
>> The reason that motivated the stronger restriction is to improve error
>> messages, because we can then error out with “multiplicity-annotated
>> let-bound patterns must be of the form !pat”, instead of the more
>> mysterious “Couldn't unify 'Many with 'One”
>> (see `#23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586>`_).
>> But maybe the additional restrictions are more surprising than the
>> error messages are helpful.
>>
>> On Mon, 8 Jan 2024 at 10:07, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> I support acceptance.  Let's land this soon.
>>>
>>> Simon
>>>
>>> On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've reviewed Arnaud's
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/624 and wish to
>>>> recommend acceptance.
>>>>
>>>> The proposal is an amendment to the proposal for linear types, adding
>>>> support for linear let bindings.
>>>>
>>>> Today, if you have
>>>>
>>>> f :: T %1-> T
>>>> f t = let t2 = t in t2
>>>>
>>>> you'll get an error because t2 is not linear. The only way to bind a
>>>> linear variable is via a `case`, never a `let` or `where`. This is
>>>> annoying. With this proposal, the little program above is accepted, with an
>>>> inferred linearity restriction on t2. Users can also annotated their lets
>>>> like `let %1 x = ... in ...`. Bindings in `where` clauses can also be
>>>> inferred or annotated as linear.
>>>>
>>>> There is a downside, of course: linear bindings have various
>>>> restrictions, chiefly that they must be strict bindings (because
>>>> projections are hard with linear types) and that bindings cannot be
>>>> generalized. I'm a little unsure that the choices in the proposal
>>>> (particularly around generalization) are the best for users, but I think
>>>> the best way to learn is to experiment. In my understanding, the community
>>>> knows that -XLinearTypes is subject to revision, and so I think we should
>>>> just blast ahead, revising if and when necessary.
>>>>
>>>> Please share your thoughts!
>>>>
>>>> Thanks,
>>>> Richard
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
>>
>>
>

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240119/5ac10e53/attachment.html>

From eric at seidel.io  Sun Jan 21 18:28:15 2024
From: eric at seidel.io (Eric Seidel)
Date: Sun, 21 Jan 2024 12:28:15 -0600
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <CAGwnsnn=v5dv3pjbFN2UMeOxOU6KHW789jsDJ8qhe=on=crRAA@mail.gmail.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
 <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
 <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>
 <CAJKmMz9rE-bVou1XUE+5fEF_Cw8EtrbH+8RhstOZcu5OLPUSWA@mail.gmail.com>
 <010f018ccf623071-9dd56897-7356-4ca2-835f-5a4df09f963e-000000@us-east-2.amazonses.com>
 <CAJKmMz9jXWzeN6THtD1SbE9wH=aFMD4XPJyLrs_=wANioJku6A@mail.gmail.com>
 <010f018ccf6dc808-374c3c04-defd-4ca5-b5fe-13db67d8e556-000000@us-east-2.amazonses.com>
 <CAJKmMz_GbawR14jEgc5YoMXuNH_FbA5p5ps5ppQwnPAacQ70+A@mail.gmail.com>
 <afdb3f88-cb9f-485a-9645-625d9e4107af@well-typed.com>
 <CAGwnsnn=v5dv3pjbFN2UMeOxOU6KHW789jsDJ8qhe=on=crRAA@mail.gmail.com>
Message-ID: <f693ec0b-f975-4b92-b0ed-85440327a54c@app.fastmail.com>

SimonM, Vlad,

The rest of the committee has expressed support for this proposal either on the ML or on SimonPJ's Google Sheet[1].

I think that is sufficient consensus to accept, but would prefer to get the full committee on record. 

Please take a few minutes to read the proposal and record your vote. Barring any explicit dissent, I will mark the proposal accepted next weekend.

Eric

[1]: https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing

On Mon, Jan 15, 2024, at 02:21, Arnaud Spiwack wrote:
> On Sat, 13 Jan 2024 at 21:42, Adam Gundry <adam at well-typed.com> wrote:
>> On the meta point, I agree with Simon's position here: we should avoid 
>> giving unconditional acceptance to underspecified proposals, only to 
>> potentially discover problems later. But where a proposal is not 
>> precisely specified, it would be preferable to accept in principle (so 
>> the author is not left wondering whether the idea has a chance) and then 
>> ask and support the author to finish the spec before merging the PR.
>
> I agree too. I was thinking about it over the weekend: we kind of need 
> a status to say “we pretty much know we're going to accept it, so go 
> ahead and do the implementation, but we're still working the details 
> out together” (I was thinking in particular of the choice of string 
> delimiters from this proposal: it makes no material difference to the 
> implementation what we eventually settle on. So if there are questions, 
> we should avoid holding the implementation effort back just because 
> we're having a discussion about what we think it best).
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From eric at seidel.io  Sun Jan 21 18:39:06 2024
From: eric at seidel.io (Eric Seidel)
Date: Sun, 21 Jan 2024 12:39:06 -0600
Subject: [ghc-steering-committee] Secretary of the GHC Steering Committee
In-Reply-To: <CAJKmMz9rRHGfYnFrCa6MokQaTYZ1UNA5AXH3CFTKuwqqwEeGag@mail.gmail.com>
References: <CAJKmMz9d+JncAP8A2VGTwSC8dXuJ1G7hnkqOa7090a+j_xhN-A@mail.gmail.com>
 <CAJKmMz9rRHGfYnFrCa6MokQaTYZ1UNA5AXH3CFTKuwqqwEeGag@mail.gmail.com>
Message-ID: <60405775-09ee-4f98-9c88-c2f657bb39da@app.fastmail.com>

Thank you Joachim for your service as Secretary! And thank you Adam for volunteering to take over!

On Thu, Jan 18, 2024, at 05:12, Simon Peyton Jones wrote:
> Dear GHC Steering Committee
>
> I got one reply (from Moritz) to my email below.  I hope that the rest 
> of you received it.
>
> That means that no one else is putting themselves forward to be 
> Secretary.  *So I declare that Adam is duly appointed as Secretary to 
> our committee*.   Thank you Adam!
>
> And renewed thanks to Joachim for being such a great Secretary.
>
> Simon
>
> On Thu, 11 Jan 2024 at 09:00, Simon Peyton Jones 
> <simon.peytonjones at gmail.com> wrote:
>> Dear GHC Steering Committee
>> 
>> Joachim's term of membership in the GHC SC comes to an end in March, and he wants to stand down as our Secretary.
>> 
>> Joachim, you have done a fantastic job as our secretary, nudging us with regular status updates, making sure we hold membership nomination processes, and much more besides.  You have made sure that we function well as a committee, and I for one have leaned heavily on your support.  Thank you so much.
>> 
>> Would anyone else like to be Secretary?  I am delighted to say that Adam is willing to serve, but if anyone else would like to join in or share the role, that would be great too.   Thank you Adam!
>> 
>> RSVP!
>> 
>> Thanks again Joachim.
>> 
>> Simon
>> 
>> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From eric at seidel.io  Sun Jan 21 18:51:16 2024
From: eric at seidel.io (Eric Seidel)
Date: Sun, 21 Jan 2024 12:51:16 -0600
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
Message-ID: <a085cc6b-83bc-42ed-b088-b64af0a33d4c@app.fastmail.com>

I feel quite distant from LinearTypes and not well positioned to opine on the specific merits of the proposal. But I will support it at the level of:

1. LinearTypes *should* be extended to support let- and where-binders if possible.
2. LinearTypes is still experimental, so we should feel free to move fast and experiment with alternatives.

On Fri, Jan 19, 2024, at 04:42, Arnaud Spiwack wrote:
> Richard seems to be the only one with a strong opinion on this. I'm 
> happy to implement Richard's recommendations (both in the proposal and 
> in the code), unless there are dissenting voices?
>
> On Wed, 17 Jan 2024 at 22:30, Richard Eisenberg <rae at richarde.dev> wrote:
>> Sorry for being vague: I support emitting the constraint equating the linearity annotation to `Many` whenever the binding is of a form that linearity can't handle, with a CtOrigin that makes for a good error message.
>> 
>> I also support allowing bang-less patterns to be linear with -XStrict; my understanding of the specification of -XStrict is that it should mean "put bangs everywhere", so accepting bang-less patterns as linear here sounds right. My hope is that this is actually a simplification, because I would imagine there some notion of "strict binding" -- encompassing both a binding with an outer ! and any binding with -XStrict -- and then this new feature just hooks into that one.
>> 
>> Richard
>> 
>>> On Jan 16, 2024, at 12:52 PM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>>> 
>>> Richard
>>> 
>>> Arnaud articulates some alternatives, which I am very fuzzy about (as I say in my email).
>>> 
>>> Can you say which alternative you support?   (I'm thinking of the language design only; I'm sure we can implement whichever design we choose.)
>>> 
>>> Simon
>>> 
>>> On Tue, 16 Jan 2024 at 18:52, Richard Eisenberg <rae at richarde.dev> wrote:
>>>> I say we have our cake and eat it, too: get better inference and better error messages. I think this shouldn't be all that hard: when emitting the constraint that the linearity of the binding is `Many`, use an appropriate `CtOrigin` that can render as an informative message. I haven't gone through the code to see exactly the best structure here, but I feel pretty confident that this should be straightforward.
>>>> 
>>>> So I'm for the design Arnaud articulates below, but support the proposal regardless.
>>>> 
>>>> Richard
>>>> 
>>>>> On Jan 12, 2024, at 3:08 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>>>>> 
>>>>> At Richard's prompting, I've added the following alternative to the proposal (the current proposal is the most conservative of the two, which we can choose to stick to if we're unsure). I'm copying the alternative here because rendering seems to be broken on Github right now.
>>>>> 
>>>>> I'm rather agnostic on which side we choose, to be honest. Anyone with medium-to-strong opinions on the question?
>>>>> 
>>>>> 
>>>>> Restrictions of multiplicity-annotated let bindings
>>>>> ---------------------------------------------------
>>>>> 
>>>>> The proposal specifies that a multiplicity annotated non-variable let binding ``let %p pat``
>>>>> must be such that ``pat = !pat'`` even if ``p = 'Many``. It is easy to
>>>>> lift this restriction on two dimension:
>>>>> 
>>>>> - We can say, instead, that patterns not of the form ``!pat'`` emit a
>>>>>   ``p ~ 'Many`` constraint instead. They already do (for the sake of
>>>>>   inference), so this is strictly less code.
>>>>> - We can generalise to more strict patterns. For instance, we don't
>>>>>   need to require a ``!`` if ``-XStrict`` is on, we can have patterns
>>>>>   of the form ``(!pat')`` (with additional parentheses). This is a few
>>>>>   lines of codes, inference actually already does this in my
>>>>>   implementation, so it's already paid for (though it does annoyingly
>>>>>   mostly duplicate another definition of strict pattern which I
>>>>>   couldn't find a way to factor as a single function, I don't like
>>>>>   this).
>>>>> 
>>>>> The reason that motivated the stronger restriction is to improve error
>>>>> messages, because we can then error out with “multiplicity-annotated
>>>>> let-bound patterns must be of the form !pat”, instead of the more
>>>>> mysterious “Couldn't unify 'Many with 'One”
>>>>> (see `#23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586>`_).
>>>>> But maybe the additional restrictions are more surprising than the
>>>>> error messages are helpful.
>>>>> 
>>>>> On Mon, 8 Jan 2024 at 10:07, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>>>>>> I support acceptance.  Let's land this soon.
>>>>>> 
>>>>>> Simon
>>>>>> 
>>>>>> On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev> wrote:
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> I've reviewed Arnaud's https://github.com/ghc-proposals/ghc-proposals/pull/624 and wish to recommend acceptance.
>>>>>>> 
>>>>>>> The proposal is an amendment to the proposal for linear types, adding support for linear let bindings.
>>>>>>> 
>>>>>>> Today, if you have
>>>>>>> 
>>>>>>> f :: T %1-> T
>>>>>>> f t = let t2 = t in t2
>>>>>>> 
>>>>>>> you'll get an error because t2 is not linear. The only way to bind a linear variable is via a `case`, never a `let` or `where`. This is annoying. With this proposal, the little program above is accepted, with an inferred linearity restriction on t2. Users can also annotated their lets like `let %1 x = ... in ...`. Bindings in `where` clauses can also be inferred or annotated as linear.
>>>>>>> 
>>>>>>> There is a downside, of course: linear bindings have various restrictions, chiefly that they must be strict bindings (because projections are hard with linear types) and that bindings cannot be generalized. I'm a little unsure that the choices in the proposal (particularly around generalization) are the best for users, but I think the best way to learn is to experiment. In my understanding, the community knows that -XLinearTypes is subject to revision, and so I think we should just blast ahead, revising if and when necessary.
>>>>>>> 
>>>>>>> Please share your thoughts!
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Richard
>>>>>>> _______________________________________________
>>>>>>> ghc-steering-committee mailing list
>>>>>>> ghc-steering-committee at haskell.org
>>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>> _______________________________________________
>>>>>> ghc-steering-committee mailing list
>>>>>> ghc-steering-committee at haskell.org
>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Arnaud Spiwack
>>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>> 
>> 
>
>
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From arnaud.spiwack at tweag.io  Mon Jan 22 08:06:10 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 22 Jan 2024 09:06:10 +0100
Subject: [ghc-steering-committee] Secretary of the GHC Steering Committee
In-Reply-To: <60405775-09ee-4f98-9c88-c2f657bb39da@app.fastmail.com>
References: <CAJKmMz9d+JncAP8A2VGTwSC8dXuJ1G7hnkqOa7090a+j_xhN-A@mail.gmail.com>
 <CAJKmMz9rRHGfYnFrCa6MokQaTYZ1UNA5AXH3CFTKuwqqwEeGag@mail.gmail.com>
 <60405775-09ee-4f98-9c88-c2f657bb39da@app.fastmail.com>
Message-ID: <CAGwnsnmm8Cu4Aux-jfvjb1dt58945xAh7P72DmphQt7VsrGBbw@mail.gmail.com>

Thank you Adam for taking this on. And many thanks to Joachim for the long
years of tireless service!

On Sun, 21 Jan 2024 at 19:39, Eric Seidel <eric at seidel.io> wrote:

> Thank you Joachim for your service as Secretary! And thank you Adam for
> volunteering to take over!
>
> On Thu, Jan 18, 2024, at 05:12, Simon Peyton Jones wrote:
> > Dear GHC Steering Committee
> >
> > I got one reply (from Moritz) to my email below.  I hope that the rest
> > of you received it.
> >
> > That means that no one else is putting themselves forward to be
> > Secretary.  *So I declare that Adam is duly appointed as Secretary to
> > our committee*.   Thank you Adam!
> >
> > And renewed thanks to Joachim for being such a great Secretary.
> >
> > Simon
> >
> > On Thu, 11 Jan 2024 at 09:00, Simon Peyton Jones
> > <simon.peytonjones at gmail.com> wrote:
> >> Dear GHC Steering Committee
> >>
> >> Joachim's term of membership in the GHC SC comes to an end in March,
> and he wants to stand down as our Secretary.
> >>
> >> Joachim, you have done a fantastic job as our secretary, nudging us
> with regular status updates, making sure we hold membership nomination
> processes, and much more besides.  You have made sure that we function well
> as a committee, and I for one have leaned heavily on your support.  Thank
> you so much.
> >>
> >> Would anyone else like to be Secretary?  I am delighted to say that
> Adam is willing to serve, but if anyone else would like to join in or share
> the role, that would be great too.   Thank you Adam!
> >>
> >> RSVP!
> >>
> >> Thanks again Joachim.
> >>
> >> Simon
> >>
> >>
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240122/aacd875b/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Jan 22 09:03:46 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 22 Jan 2024 09:03:46 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
Message-ID: <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>

 Richard seems to be the only one with a strong opinion on this. I'm happy
to implement Richard's recommendations (both in the proposal and in the
code), unless there are dissenting voices?

I am still struggling to understand the choice that you are putting before
us.  I laid out my understanding last week:

   - I think that the issue you are debating only arises when you, the
   programmer, want to *explicitly annotate *a let/where binding with a
   multiplicity.  Right?
   - I think that you are saying that all bindings with a *non-Many
*multiplicity
   *must *be strict.
   - I think the choices you are identifying are:
      - If the explicit annotation is Many, does the binding still need to
      be strict?
      - If the binding needs to be strict, do we insist on an explicit !
      or, if -XStrict is on can we omit that bang?

Can I ask if my understanding is correct?

Assuming so, to me the most straightforward and conservative thing is:

   - All multiplicity-annotated pattern bindings must have an explicit
   bang, thus   let %p !pat = rhs

This rule is simple, direct, and explicable.  No one is going to write a
multiplicity-annotated pattern binding let %Many pat = rhs, so it's not
worth optimising for that case.

Simon

On Fri, 19 Jan 2024 at 10:42, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Richard seems to be the only one with a strong opinion on this. I'm happy
> to implement Richard's recommendations (both in the proposal and in the
> code), unless there are dissenting voices?
>
> On Wed, 17 Jan 2024 at 22:30, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> Sorry for being vague: I support emitting the constraint equating the
>> linearity annotation to `Many` whenever the binding is of a form that
>> linearity can't handle, with a CtOrigin that makes for a good error message.
>>
>> I also support allowing bang-less patterns to be linear with -XStrict; my
>> understanding of the specification of -XStrict is that it should mean "put
>> bangs everywhere", so accepting bang-less patterns as linear here sounds
>> right. My hope is that this is actually a simplification, because I would
>> imagine there some notion of "strict binding" -- encompassing both a
>> binding with an outer ! and any binding with -XStrict -- and then this new
>> feature just hooks into that one.
>>
>> Richard
>>
>> On Jan 16, 2024, at 12:52 PM, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>> Richard
>>
>> Arnaud articulates some alternatives, which I am very fuzzy about (as I
>> say in my email).
>>
>> Can you say which alternative you support?   (I'm thinking of the
>> language design only; I'm sure we can implement whichever design we choose.)
>>
>> Simon
>>
>> On Tue, 16 Jan 2024 at 18:52, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>>> I say we have our cake and eat it, too: get better inference and better
>>> error messages. I think this shouldn't be all that hard: when emitting the
>>> constraint that the linearity of the binding is `Many`, use an appropriate
>>> `CtOrigin` that can render as an informative message. I haven't gone
>>> through the code to see exactly the best structure here, but I feel pretty
>>> confident that this should be straightforward.
>>>
>>> So I'm for the design Arnaud articulates below, but support the proposal
>>> regardless.
>>>
>>> Richard
>>>
>>> On Jan 12, 2024, at 3:08 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>> At Richard's prompting, I've added the following alternative to the
>>> proposal (the current proposal is the most conservative of the two, which
>>> we can choose to stick to if we're unsure). I'm copying the alternative
>>> here because rendering seems to be broken on Github right now.
>>>
>>> I'm rather agnostic on which side we choose, to be honest. Anyone with
>>> medium-to-strong opinions on the question?
>>>
>>>
>>> Restrictions of multiplicity-annotated let bindings
>>> ---------------------------------------------------
>>>
>>> The proposal specifies that a multiplicity annotated non-variable let
>>> binding ``let %p pat``
>>> must be such that ``pat = !pat'`` even if ``p = 'Many``. It is easy to
>>> lift this restriction on two dimension:
>>>
>>> - We can say, instead, that patterns not of the form ``!pat'`` emit a
>>>   ``p ~ 'Many`` constraint instead. They already do (for the sake of
>>>   inference), so this is strictly less code.
>>> - We can generalise to more strict patterns. For instance, we don't
>>>   need to require a ``!`` if ``-XStrict`` is on, we can have patterns
>>>   of the form ``(!pat')`` (with additional parentheses). This is a few
>>>   lines of codes, inference actually already does this in my
>>>   implementation, so it's already paid for (though it does annoyingly
>>>   mostly duplicate another definition of strict pattern which I
>>>   couldn't find a way to factor as a single function, I don't like
>>>   this).
>>>
>>> The reason that motivated the stronger restriction is to improve error
>>> messages, because we can then error out with “multiplicity-annotated
>>> let-bound patterns must be of the form !pat”, instead of the more
>>> mysterious “Couldn't unify 'Many with 'One”
>>> (see `#23586 <https://gitlab.haskell.org/ghc/ghc/-/issues/23586>`_).
>>> But maybe the additional restrictions are more surprising than the
>>> error messages are helpful.
>>>
>>> On Mon, 8 Jan 2024 at 10:07, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> I support acceptance.  Let's land this soon.
>>>>
>>>> Simon
>>>>
>>>> On Sat, 6 Jan 2024 at 04:45, Richard Eisenberg <rae at richarde.dev>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I've reviewed Arnaud's
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/624 and wish to
>>>>> recommend acceptance.
>>>>>
>>>>> The proposal is an amendment to the proposal for linear types, adding
>>>>> support for linear let bindings.
>>>>>
>>>>> Today, if you have
>>>>>
>>>>> f :: T %1-> T
>>>>> f t = let t2 = t in t2
>>>>>
>>>>> you'll get an error because t2 is not linear. The only way to bind a
>>>>> linear variable is via a `case`, never a `let` or `where`. This is
>>>>> annoying. With this proposal, the little program above is accepted, with an
>>>>> inferred linearity restriction on t2. Users can also annotated their lets
>>>>> like `let %1 x = ... in ...`. Bindings in `where` clauses can also be
>>>>> inferred or annotated as linear.
>>>>>
>>>>> There is a downside, of course: linear bindings have various
>>>>> restrictions, chiefly that they must be strict bindings (because
>>>>> projections are hard with linear types) and that bindings cannot be
>>>>> generalized. I'm a little unsure that the choices in the proposal
>>>>> (particularly around generalization) are the best for users, but I think
>>>>> the best way to learn is to experiment. In my understanding, the community
>>>>> knows that -XLinearTypes is subject to revision, and so I think we should
>>>>> just blast ahead, revising if and when necessary.
>>>>>
>>>>> Please share your thoughts!
>>>>>
>>>>> Thanks,
>>>>> Richard
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>
>>>
>>>
>>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240122/50104e6a/attachment.html>

From arnaud.spiwack at tweag.io  Mon Jan 22 10:00:15 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 22 Jan 2024 11:00:15 +0100
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
 <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
Message-ID: <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>

On Mon, 22 Jan 2024 at 10:04, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Richard seems to be the only one with a strong opinion on this. I'm happy
> to implement Richard's recommendations (both in the proposal and in the
> code), unless there are dissenting voices?
>
> I am still struggling to understand the choice that you are putting before
> us.  I laid out my understanding last week:
>
>    - I think that the issue you are debating only arises when you, the
>    programmer, want to *explicitly annotate *a let/where binding with a
>    multiplicity.  Right?
>    - I think that you are saying that all bindings with a *non-Many *multiplicity
>    *must *be strict.
>    - I think the choices you are identifying are:
>       - If the explicit annotation is Many, does the binding still need
>       to be strict?
>       - If the binding needs to be strict, do we insist on an explicit !
>       or, if -XStrict is on can we omit that bang?
>
> Can I ask if my understanding is correct?
>

It is, with two caveats:
- the question of whether a pattern is strict also shows up when we infer
the multiplicity of an unannotated let-binding. In this case, if the
non-variable pattern isn't strict, then we emit a multiplicity-must-be-Many
constraint. And the same choice (should we consider some patterns as strict
when they aren't annotated with `!`) arises.
- beside the -XStrict question, there is the question of whether `(!p)`
(with parentheses) is considered strict.

Here's the full logic I've considered so far (where `checkManyPattern`
means: must be Many, and `return WpHole` means: no constraint on the
multiplicity):

    manyIfLazy dflags lpat
      | xopt LangExt.Strict dflags = xstrict lpat
      | otherwise = not_xstrict lpat
      where
        xstrict (L _ (LazyPat _ _)) = checkManyPattern pat_ty
        xstrict (L _ (ParPat _ _ p _)) = xstrict p
        xstrict _ = return WpHole

        not_xstrict (L _ (BangPat _ _)) = return WpHole
        not_xstrict (L _ (VarPat _ _)) = return WpHole
        not_xstrict (L _ (ParPat _ _ p _)) = not_xstrict p
        not_xstrict _ = checkManyPattern pat_ty




> Assuming so, to me the most straightforward and conservative thing is:
>
>    - All multiplicity-annotated pattern bindings must have an explicit
>    bang, thus   let %p !pat = rhs
>
> This rule is simple, direct, and explicable.  No one is going to write a
> multiplicity-annotated pattern binding let %Many pat = rhs, so it's not
> worth optimising for that case.
>

It's certainly the more conservative option. But Richard was arguing that
it's too conservative. As for explicability: which of “the pattern must be
strict” or “the pattern must be annotated with a !” is easier to explain?
I'm not sure, but here's some food for thought: if we settle on “annotated
with a !”, then how do we explain that patterns in case branches don't need
to be annotated with a “!"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240122/b1dfc7dd/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Jan 22 16:29:24 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 22 Jan 2024 16:29:24 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
 <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
 <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>
Message-ID: <CAJKmMz8=DGDcu9WeXe=vQtPGqjk+DnedB1KtiWARzeQrQPTang@mail.gmail.com>

I suggest:

   - A pattern pat is called *banged *iff it is of form !pat, or (pat)
   where pat is banged.
   - A pattern binding pat = rhs, *without a user-specified multiplicity
   annotation*
      - has multiplicity Many ifpat is not banged
      - If p is banged, it gets an inferred multiplicity (somehow).
   - In a pattern binding %p pat = rhs, *with an explicit user-specified
   multiplicity annotation %p*
      - the pattern pat must be banged regardless of  p.

I don't think patterns in case branches are involved.  These rules concern
pattern bindings pat=rhe

Simon

On Mon, 22 Jan 2024 at 10:00, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

>
>
> On Mon, 22 Jan 2024 at 10:04, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Richard seems to be the only one with a strong opinion on this. I'm happy
>> to implement Richard's recommendations (both in the proposal and in the
>> code), unless there are dissenting voices?
>>
>> I am still struggling to understand the choice that you are putting
>> before us.  I laid out my understanding last week:
>>
>>    - I think that the issue you are debating only arises when you, the
>>    programmer, want to *explicitly annotate *a let/where binding with a
>>    multiplicity.  Right?
>>    - I think that you are saying that all bindings with a *non-Many *multiplicity
>>    *must *be strict.
>>    - I think the choices you are identifying are:
>>       - If the explicit annotation is Many, does the binding still need
>>       to be strict?
>>       - If the binding needs to be strict, do we insist on an explicit !
>>       or, if -XStrict is on can we omit that bang?
>>
>> Can I ask if my understanding is correct?
>>
>
> It is, with two caveats:
> - the question of whether a pattern is strict also shows up when we infer
> the multiplicity of an unannotated let-binding. In this case, if the
> non-variable pattern isn't strict, then we emit a multiplicity-must-be-Many
> constraint. And the same choice (should we consider some patterns as strict
> when they aren't annotated with `!`) arises.
> - beside the -XStrict question, there is the question of whether `(!p)`
> (with parentheses) is considered strict.
>
> Here's the full logic I've considered so far (where `checkManyPattern`
> means: must be Many, and `return WpHole` means: no constraint on the
> multiplicity):
>
>     manyIfLazy dflags lpat
>       | xopt LangExt.Strict dflags = xstrict lpat
>       | otherwise = not_xstrict lpat
>       where
>         xstrict (L _ (LazyPat _ _)) = checkManyPattern pat_ty
>         xstrict (L _ (ParPat _ _ p _)) = xstrict p
>         xstrict _ = return WpHole
>
>         not_xstrict (L _ (BangPat _ _)) = return WpHole
>         not_xstrict (L _ (VarPat _ _)) = return WpHole
>         not_xstrict (L _ (ParPat _ _ p _)) = not_xstrict p
>         not_xstrict _ = checkManyPattern pat_ty
>
>
>
>
>> Assuming so, to me the most straightforward and conservative thing is:
>>
>>    - All multiplicity-annotated pattern bindings must have an explicit
>>    bang, thus   let %p !pat = rhs
>>
>> This rule is simple, direct, and explicable.  No one is going to write a
>> multiplicity-annotated pattern binding let %Many pat = rhs, so it's not
>> worth optimising for that case.
>>
>
> It's certainly the more conservative option. But Richard was arguing that
> it's too conservative. As for explicability: which of “the pattern must be
> strict” or “the pattern must be annotated with a !” is easier to explain?
> I'm not sure, but here's some food for thought: if we settle on “annotated
> with a !”, then how do we explain that patterns in case branches don't need
> to be annotated with a “!"?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240122/652231c4/attachment.html>

From adam at well-typed.com  Mon Jan 22 20:47:19 2024
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 22 Jan 2024 20:47:19 +0000
Subject: [ghc-steering-committee] Secretary of the GHC Steering Committee
In-Reply-To: <CAGwnsnmm8Cu4Aux-jfvjb1dt58945xAh7P72DmphQt7VsrGBbw@mail.gmail.com>
References: <CAJKmMz9d+JncAP8A2VGTwSC8dXuJ1G7hnkqOa7090a+j_xhN-A@mail.gmail.com>
 <CAJKmMz9rRHGfYnFrCa6MokQaTYZ1UNA5AXH3CFTKuwqqwEeGag@mail.gmail.com>
 <60405775-09ee-4f98-9c88-c2f657bb39da@app.fastmail.com>
 <CAGwnsnmm8Cu4Aux-jfvjb1dt58945xAh7P72DmphQt7VsrGBbw@mail.gmail.com>
Message-ID: <cd9d42fd-648f-4450-8271-a3727232dcf6@well-typed.com>

Thanks everyone. As it's time for a new nomination round for committee 
memberships, I will look to organise this over the next few weeks. 
(Joachim, if you have any particular pointers for how to do this, e.g. 
regarding the specific voting mechanism you've used in previous rounds, 
that would be welcome.)

I'm also planning to do a pass over the README, by-laws, process 
documentation etc. as I think a few updates may be in order. In 
particular I'd like to think through how we can avoid proposals 
languishing for too long waiting on committee responses.

Cheers,

Adam



On 22/01/2024 08:06, Arnaud Spiwack wrote:
> Thank you Adam for taking this on. And many thanks to Joachim for the 
> long years of tireless service!
> 
> On Sun, 21 Jan 2024 at 19:39, Eric Seidel <eric at seidel.io 
> <mailto:eric at seidel.io>> wrote:
> 
>     Thank you Joachim for your service as Secretary! And thank you Adam
>     for volunteering to take over!
> 
>     On Thu, Jan 18, 2024, at 05:12, Simon Peyton Jones wrote:
>      > Dear GHC Steering Committee
>      >
>      > I got one reply (from Moritz) to my email below.  I hope that the
>     rest
>      > of you received it.
>      >
>      > That means that no one else is putting themselves forward to be
>      > Secretary.  *So I declare that Adam is duly appointed as
>     Secretary to
>      > our committee*.   Thank you Adam!
>      >
>      > And renewed thanks to Joachim for being such a great Secretary.
>      >
>      > Simon
>      >
>      > On Thu, 11 Jan 2024 at 09:00, Simon Peyton Jones
>      > <simon.peytonjones at gmail.com
>     <mailto:simon.peytonjones at gmail.com>> wrote:
>      >> Dear GHC Steering Committee
>      >>
>      >> Joachim's term of membership in the GHC SC comes to an end in
>     March, and he wants to stand down as our Secretary.
>      >>
>      >> Joachim, you have done a fantastic job as our secretary, nudging
>     us with regular status updates, making sure we hold membership
>     nomination processes, and much more besides.  You have made sure
>     that we function well as a committee, and I for one have leaned
>     heavily on your support.  Thank you so much.
>      >>
>      >> Would anyone else like to be Secretary?  I am delighted to say
>     that Adam is willing to serve, but if anyone else would like to join
>     in or share the role, that would be great too.   Thank you Adam!
>      >>
>      >> RSVP!
>      >>
>      >> Thanks again Joachim.
>      >>
>      >> Simon

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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From adam at well-typed.com  Mon Jan 22 21:02:20 2024
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 22 Jan 2024 21:02:20 +0000
Subject: [ghc-steering-committee] #493: SPECIALISE with expressions,
 rec: accept
In-Reply-To: <CAGwnsnmo704VsXMQjjzWURMmJoSzap7qun_yFHxfZrVV2T7dtQ@mail.gmail.com>
References: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com>
 <CAJKmMz-t6=D--9zWbuNotpJbdmx0q12fiO0=jYrAic4ykx8-1A@mail.gmail.com>
 <beba9def-eddd-4b52-b676-8e2509c66dba@app.fastmail.com>
 <26ec8e4a-3fd2-4cde-b153-dd9a238569aa@well-typed.com>
 <CAGwnsnmo704VsXMQjjzWURMmJoSzap7qun_yFHxfZrVV2T7dtQ@mail.gmail.com>
Message-ID: <fe2df5cf-2776-40f5-b850-03ebd64c57eb@well-typed.com>

In the absence of further discussion, I've declared this proposal to be 
accepted. Thanks Richard and Simon!

Adam


On 11/01/2024 13:06, Arnaud Spiwack wrote:
> Simon amended the proposal to say just that more or less at the same 
> time as your email.
> 
> At any rate, I think we should accept the proposal regardless of 
> deprecation. Both choices are equally reasonable in my opinion.
> 
> On Thu, 11 Jan 2024 at 10:55, Adam Gundry <adam at well-typed.com 
> <mailto:adam at well-typed.com>> wrote:
> 
>     Hi everyone,
> 
>     I believe there is broad consensus to accept this proposal. One
>     point of
>     detail that has arisen on the proposal thread
>     (https://github.com/ghc-proposals/ghc-proposals/pull/493#issuecomment-1831697143 <https://github.com/ghc-proposals/ghc-proposals/pull/493#issuecomment-1831697143>)
>     is whether to deprecate and remove the awkward and undocumented
>     multi-type form
> 
>           {-# SPECIALISE f :: Int -> Int
>                            , Bool -> Bool
>                            , Float -> Float #-}
> 
>     since users can equally well write the clearer
> 
>           {-# SPECIALISE f :: Int -> Int #-}
>           {-# SPECIALISE f :: Bool -> Bool #-}
>           {-# SPECIALISE f :: Float -> Float #-}
> 
>     The current text of the proposal retains the multi-type form, but
>     discussion on the proposal thread suggests deprecating it instead,
>     subject to the usual requirement that if/when this is implemented, GHC
>     will issue a warning and continue to accept the old syntax for at least
>     3 releases before completely removing it.
> 
>     I suggest we accept the proposal on the basis that it will be
>     amended to
>     deprecate the multi-type form. If you disagree, please object in the
>     next week or so.
> 
>     Cheers,
> 
>     Adam
> 
> 
> 
>     On 19/12/2023 03:02, Eric Seidel wrote:
>      > Apologies, this sounds like an obvious win. +1
>      >
>      > On Mon, Dec 18, 2023, at 04:36, Simon Peyton Jones wrote:
>      >> Eric, Joachim, Chris
>      >>
>      >> You have not yet responded (I think) to Adam's recommendation. 
>        RSVP!
>      >>
>      >>
>     https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>
>      >>
>      >> Simon
>      >>
>      >> On Wed, 29 Nov 2023 at 08:25, Adam Gundry <adam at well-typed.com
>     <mailto:adam at well-typed.com>> wrote:
>      >>> Dear all,
>      >>>
>      >>> Richard and Simon propose to generalise SPECIALISE pragmas to allow
>      >>> expressions, not just type signatures:
>      >>>
>      >>> https://github.com/ghc-proposals/ghc-proposals/pull/493
>     <https://github.com/ghc-proposals/ghc-proposals/pull/493>
>      >>>
>     https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst <https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst>
>      >>>
>      >>> This does not add anything fundamentally new, because such
>     SPECIALISE
>      >>> pragmas can be translated using the existing RULES machinery,
>     but it
>      >>> does make several idioms substantially more convenient:
>      >>>
>      >>>    * Using type applications in a SPECIALISE pragma to avoid
>     repetition
>      >>>
>      >>>    * Manual call-pattern specialisation
>      >>>
>      >>>    * Loop unrolling
>      >>>
>      >>> Thus I propose we accept this proposal.
>      >>>
>      >>> Cheers,
>      >>>
>      >>> Adam


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From mail at joachim-breitner.de  Mon Jan 22 21:47:24 2024
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 22 Jan 2024 22:47:24 +0100
Subject: [ghc-steering-committee] GHC Steering Committee Status
Message-ID: <fe559a2ea9db96106c280cc65036f0f6c78be516.camel@joachim-breitner.de>

Dear Committee,

I guess it’s time for a final status summary for me, to leave this
place in good order for Adam to take over. Indeed, it is long due, the
last one was on Sept 9. What happened since then?

 * Our chairs, the Simons, will serve another term.

 * GHC2024 proposed, discussed, voted upon and accepted. Although
   now there is pushback against making it the out-of-the-box experience,
   which is stalling the MR. If someone feels strongly, they should probably
   make a proposal.

 * Simon introduced a spreadsheet to keep better track of ongoing
   proposals:
   https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing

 * We had various discussions around stability in various venues,
   eventually converging in a document at
   https://docs.google.com/document/d/1sX_rXHx8Mj3Kae9GalR2BwZ5-xzl7UpnpMBwl4dqsWY/edit?usp=sharing
   and the proposal at https://github.com/ghc-proposals/ghc-proposals/pull/625

 * we were asked to review these proposals:

   #571: -Wsevere, Shepherd: Adam  
   #569: multiline string literals, Shepherd: Eric
   #612: -fhpc tix file changes, Shepherd: Moritz
   #606: 281 to use atype instead of ktype, Shepherd: Richard
   #624: Linear lets, Shepherd: Richard
   #626: Visible Forall in Types, Shepherd: Arnaud
   #625: Stability Goals, Shepherd: Moritz

 * we have a recommendation from the shepherd about:

   #434: Fine-grained unused warnings, rec: accept
   #609: Amend or-patterns to use ;, rec: accept
   #571: -Wsevere, rec: accept
   #526: Applicative Comprehensions, rec: accept
   #493: SPECIALISE with expressions, rec: accept
   #626: Amendment of Visible Forall in Types, recommendation: Accept
   #569: multiline string literals; Rec: accept
   #624: linear let-bindings; recommendation: accept

 * we have sent the following proposals back to revision

   #193: Updated partial type signatures
   #526: Applicative Comprehensions (dormant)
   #536: Type-level literals as a sep language extension

 * we decided about the following proposals

   #583: HasField redesign, accept
   #626: Amendment of Visible Forall in Types, accept
   #493: SPECIALISE with expressions: accept
   #585: Amend Or Patterns (merged as #609), accept


So we currently have to act on the following 9 proposals,
same number than last time (but luckily different proposals).

## Waiting for committee decision

#512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
      2022-09-03: Assigned to Baldur
      2022-10-02: Reassignd to Vlad
      2022-11-30: Vlad recommends rejection
      2023-12-11: Vlads most recent push for a resolution
      Last suggestion was a “conditional accept”. Guess
      we should do that.

#569: Multi-line string literals, Shepherd: Eric
      Acceptance pending, I believe

#434: Fine-grained unused warnings, Shepherd: Chris
      2023-07-90: Assigned to Chris
      2023-09-09: Acceptance suggested
      Mostly positive responses

#624: linear let-bindings
      2023-12-07: Assigned to Richard
      2024-01-06: Acceptance recommended

## Waiting for shepherd recommendation

#597: Constraints synonyms in deriving heads
      2023-07-25 Assigned to Moritz

#606: 281 to use atype instead of ktype, 
      2023-11-30 Assigned to Richard

#608: no implicit bindings with -XPatternSignatures
      2023-08-17: Assinged to Richard

#612: -fhpc tix file changes
      2023-09-27: Assigned to Moritz

#625: Stability Goals
      2023-12-18: Assigned to Moritz


With that I’d like to say thanks you all for bearing with my
secretarial whims throughout the years and never ever once complaining
about my sometimes Machiavellian shephard assignments. And thanks in
particular to Adam to take over so readily; I believe the proposals are
in good hands with you.


Cheers,
Joachim



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


From rae at richarde.dev  Wed Jan 24 14:07:34 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 24 Jan 2024 14:07:34 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAJKmMz8=DGDcu9WeXe=vQtPGqjk+DnedB1KtiWARzeQrQPTang@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
 <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
 <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>
 <CAJKmMz8=DGDcu9WeXe=vQtPGqjk+DnedB1KtiWARzeQrQPTang@mail.gmail.com>
Message-ID: <010f018d3bcc309a-a9101718-cd2b-4554-a4a3-e1ef8bd91794-000000@us-east-2.amazonses.com>

I find Simon's rules put too much emphasis on syntax (the appearance of a ! mark), whereas I'm arguing in favor of basing the rules on semantics (is the binding strict). But I'm happy to concede the point; I just think my proposal is actually simpler (and should be so in the implementation, but I might be wrong).

One small correction to Simon's description: this is all about non-variable patterns. A variable pattern is allowed to be linear (e.g. let %1 x = f y in ...) even without a bang or other source of strictness.

Richard

> On Jan 22, 2024, at 4:29 PM, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> 
> I suggest:
> A pattern pat is called banged iff it is of form !pat, or (pat) where pat is banged.
> A pattern binding pat = rhs, without a user-specified multiplicity annotation
> has multiplicity Many ifpat is not banged
> If p is banged, it gets an inferred multiplicity (somehow).
> In a pattern binding %p pat = rhs, with an explicit user-specified multiplicity annotation %p
> the pattern pat must be banged regardless of  p.
> I don't think patterns in case branches are involved.  These rules concern pattern bindings pat=rhe
> 
> Simon
> 
> On Mon, 22 Jan 2024 at 10:00, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
> 
> On Mon, 22 Jan 2024 at 10:04, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> Richard seems to be the only one with a strong opinion on this. I'm happy to implement Richard's recommendations (both in the proposal and in the code), unless there are dissenting voices? 
> 
> I am still struggling to understand the choice that you are putting before us.  I laid out my understanding last week:
> I think that the issue you are debating only arises when you, the programmer, want to explicitly annotate a let/where binding with a multiplicity.  Right?
> I think that you are saying that all bindings with a non-Many multiplicity must be strict.
> I think the choices you are identifying are:
> If the explicit annotation is Many, does the binding still need to be strict?
> If the binding needs to be strict, do we insist on an explicit ! or, if -XStrict is on can we omit that bang?
> Can I ask if my understanding is correct?
> 
> It is, with two caveats:
> - the question of whether a pattern is strict also shows up when we infer the multiplicity of an unannotated let-binding. In this case, if the non-variable pattern isn't strict, then we emit a multiplicity-must-be-Many constraint. And the same choice (should we consider some patterns as strict when they aren't annotated with `!`) arises.
> - beside the -XStrict question, there is the question of whether `(!p)` (with parentheses) is considered strict.
> 
> Here's the full logic I've considered so far (where `checkManyPattern` means: must be Many, and `return WpHole` means: no constraint on the multiplicity):
> 
>     manyIfLazy dflags lpat
>       | xopt LangExt.Strict dflags = xstrict lpat
>       | otherwise = not_xstrict lpat
>       where
>         xstrict (L _ (LazyPat _ _)) = checkManyPattern pat_ty
>         xstrict (L _ (ParPat _ _ p _)) = xstrict p
>         xstrict _ = return WpHole
> 
>         not_xstrict (L _ (BangPat _ _)) = return WpHole
>         not_xstrict (L _ (VarPat _ _)) = return WpHole
>         not_xstrict (L _ (ParPat _ _ p _)) = not_xstrict p
>         not_xstrict _ = checkManyPattern pat_ty
> 
> 
>  
> Assuming so, to me the most straightforward and conservative thing is:
> All multiplicity-annotated pattern bindings must have an explicit bang, thus   let %p !pat = rhs
> This rule is simple, direct, and explicable.  No one is going to write a multiplicity-annotated pattern binding let %Many pat = rhs, so it's not worth optimising for that case.
> 
> It's certainly the more conservative option. But Richard was arguing that it's too conservative. As for explicability: which of “the pattern must be strict” or “the pattern must be annotated with a !” is easier to explain? I'm not sure, but here's some food for thought: if we settle on “annotated with a !”, then how do we explain that patterns in case branches don't need to be annotated with a “!"?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240124/0eef38bc/attachment.html>

From simon.peytonjones at gmail.com  Wed Jan 24 15:39:28 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 24 Jan 2024 15:39:28 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <010f018d3bcc309a-a9101718-cd2b-4554-a4a3-e1ef8bd91794-000000@us-east-2.amazonses.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
 <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
 <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>
 <CAJKmMz8=DGDcu9WeXe=vQtPGqjk+DnedB1KtiWARzeQrQPTang@mail.gmail.com>
 <010f018d3bcc309a-a9101718-cd2b-4554-a4a3-e1ef8bd91794-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz-OVmHSSYcR1gu-68-E2iPBEvKE1SornN1O6NAxwKgDEA@mail.gmail.com>

I do not feel strongly. I am content for Arnaud to make a choice, and make
sure that it is clearly expressed in the final version of the spec.

One small correction to Simon's description: this is all about non-variable
> patterns. A variable pattern is allowed to be linear (e.g. let %1 x = f y
> in ...) even without a bang or other source of strictness.


I did not know that.   Can the proposal spell this out explicitly please?

Do newtypes make a difference?  E.g      let N x = e in ...
where N is the data contructor of a newtype?

Simon

On Wed, 24 Jan 2024 at 14:07, Richard Eisenberg <rae at richarde.dev> wrote:

> I find Simon's rules put too much emphasis on syntax (the appearance of a
> ! mark), whereas I'm arguing in favor of basing the rules on semantics (is
> the binding strict). But I'm happy to concede the point; I just think my
> proposal is actually simpler (and should be so in the implementation, but I
> might be wrong).
>
> One small correction to Simon's description: this is all about
> non-variable patterns. A variable pattern is allowed to be linear (e.g. let
> %1 x = f y in ...) even without a bang or other source of strictness.
>
> Richard
>
> On Jan 22, 2024, at 4:29 PM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
> I suggest:
>
>    - A pattern pat is called *banged *iff it is of form !pat, or (pat)
>    where pat is banged.
>    - A pattern binding pat = rhs, *without a user-specified multiplicity
>    annotation*
>       - has multiplicity Many ifpat is not banged
>       - If p is banged, it gets an inferred multiplicity (somehow).
>    - In a pattern binding %p pat = rhs, *with an explicit user-specified
>    multiplicity annotation %p*
>       - the pattern pat must be banged regardless of  p.
>
> I don't think patterns in case branches are involved.  These rules concern
> pattern bindings pat=rhe
>
> Simon
>
> On Mon, 22 Jan 2024 at 10:00, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>>
>>
>> On Mon, 22 Jan 2024 at 10:04, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Richard seems to be the only one with a strong opinion on this. I'm
>>> happy to implement Richard's recommendations (both in the proposal and in
>>> the code), unless there are dissenting voices?
>>>
>>> I am still struggling to understand the choice that you are putting
>>> before us.  I laid out my understanding last week:
>>>
>>>    - I think that the issue you are debating only arises when you, the
>>>    programmer, want to *explicitly annotate *a let/where binding with a
>>>    multiplicity.  Right?
>>>    - I think that you are saying that all bindings with a *non-Many *multiplicity
>>>    *must *be strict.
>>>    - I think the choices you are identifying are:
>>>       - If the explicit annotation is Many, does the binding still need
>>>       to be strict?
>>>       - If the binding needs to be strict, do we insist on an explicit
>>>       ! or, if -XStrict is on can we omit that bang?
>>>
>>> Can I ask if my understanding is correct?
>>>
>>
>> It is, with two caveats:
>> - the question of whether a pattern is strict also shows up when we infer
>> the multiplicity of an unannotated let-binding. In this case, if the
>> non-variable pattern isn't strict, then we emit a multiplicity-must-be-Many
>> constraint. And the same choice (should we consider some patterns as strict
>> when they aren't annotated with `!`) arises.
>> - beside the -XStrict question, there is the question of whether `(!p)`
>> (with parentheses) is considered strict.
>>
>> Here's the full logic I've considered so far (where `checkManyPattern`
>> means: must be Many, and `return WpHole` means: no constraint on the
>> multiplicity):
>>
>>     manyIfLazy dflags lpat
>>       | xopt LangExt.Strict dflags = xstrict lpat
>>       | otherwise = not_xstrict lpat
>>       where
>>         xstrict (L _ (LazyPat _ _)) = checkManyPattern pat_ty
>>         xstrict (L _ (ParPat _ _ p _)) = xstrict p
>>         xstrict _ = return WpHole
>>
>>         not_xstrict (L _ (BangPat _ _)) = return WpHole
>>         not_xstrict (L _ (VarPat _ _)) = return WpHole
>>         not_xstrict (L _ (ParPat _ _ p _)) = not_xstrict p
>>         not_xstrict _ = checkManyPattern pat_ty
>>
>>
>>
>>
>>> Assuming so, to me the most straightforward and conservative thing is:
>>>
>>>    - All multiplicity-annotated pattern bindings must have an explicit
>>>    bang, thus   let %p !pat = rhs
>>>
>>> This rule is simple, direct, and explicable.  No one is going to write a
>>> multiplicity-annotated pattern binding let %Many pat = rhs, so it's not
>>> worth optimising for that case.
>>>
>>
>> It's certainly the more conservative option. But Richard was arguing that
>> it's too conservative. As for explicability: which of “the pattern must be
>> strict” or “the pattern must be annotated with a !” is easier to explain?
>> I'm not sure, but here's some food for thought: if we settle on “annotated
>> with a !”, then how do we explain that patterns in case branches don't need
>> to be annotated with a “!"?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240124/576a5491/attachment-0001.html>

From arnaud.spiwack at tweag.io  Wed Jan 24 16:38:59 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Wed, 24 Jan 2024 17:38:59 +0100
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAJKmMz-OVmHSSYcR1gu-68-E2iPBEvKE1SornN1O6NAxwKgDEA@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
 <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
 <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>
 <CAJKmMz8=DGDcu9WeXe=vQtPGqjk+DnedB1KtiWARzeQrQPTang@mail.gmail.com>
 <010f018d3bcc309a-a9101718-cd2b-4554-a4a3-e1ef8bd91794-000000@us-east-2.amazonses.com>
 <CAJKmMz-OVmHSSYcR1gu-68-E2iPBEvKE1SornN1O6NAxwKgDEA@mail.gmail.com>
Message-ID: <CAGwnsnmz21QTwKFc_9ANL8=BvFXer9ZPD9g_oaupWUo8NyJUiw@mail.gmail.com>

On Wed, 24 Jan 2024 at 16:39, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Do newtypes make a difference?  E.g      let N x = e in ...
> where N is the data contructor of a newtype?
>

I don't think it has too. So for the moment, I vote to stick to the current
proposal and consider this like all lazy non-variable patterns: must be
unrestricted.

I suspect that there's a possible refinement where we say that a happy
pattern is either:
- A variable
- Strict
- A newtype constructor where the inner pattern is happy.

(then if pat is an unhappy pattern, `let pat` must be unrestricted).

But I don't think I'm quite ready to go there for the time being, and
that'll be a backward compatible change if we change our mind.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240124/5cb2e18d/attachment.html>

From rae at richarde.dev  Wed Jan 24 17:32:39 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 24 Jan 2024 17:32:39 +0000
Subject: [ghc-steering-committee] Proposal #608,
	-XPatternSignatureBinds. Rec: accept
Message-ID: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>

John Ericson has submitted proposal #608 <https://github.com/ghc-proposals/ghc-proposals/pull/608> about adding -XPatternSignatureBinds. The proposal is an amendment and is thus a little harder to consume. I recommend reading the summary here.

Proposed change:

The proposed -XPatternSignatureBinds takes a piece out from -XPatternSignatures: with only -XPatternSignatures and not -XPatternSignatureBinds, a pattern signature  can mention in-scope type variables but can never bind fresh ones. With -XPatternSignatureBinds, an appearance of an out-of-scope type variable in a pattern signature will cause the variable to be bound to the type it unifies with.

-XScopedTypeVariables will imply -XPatternSignatures -XPatternSignatureBinds (and a few more), so the behavior of -XScopedTypeVariables is completely unchanged. Note that -XPatternSignatures is currently deprecated (and has been so for a long time), so a change in behavior there is not so bad.

Motivation for the change:

- It is awkward to have a rule in a language where scoping behavior depends on what else is in scope. This can confound e.g. tools meant to find the bindings sites of a variable occurrence.
- The implicit binding we have today plays poorly with the plan to allow users to pretend GHC has a unified namespace. That is, suppose x is in scope as a term variable, and then we have f (... :: ... x ...) = ... . Should that x be bound implicitly there or not? It's pretty unclear. By separating out -XPatternSignatureBinds from -XPatternSignatures, users of the latter are insulated from worrying about this potential future change.

My opinion:

- John has argued that this will make future namespace changes easier. I disagree with this assessment, because -XScopedTypeVariables is utterly pervasive. So the problem that this change is supposed to solve becomes only a tiny bit smaller, benefiting only those users who carefully enable -XPatternSignatures but not, say, -XScopedTypeVariables.
- But in the end, I don't care all that much. I've come to the opinion that we shouldn't worry about the distinction between warnings and extensions. The net effect of this proposal is to promote a warning into an extension (because we previously had -Wpattern-signature-binds). So if we shouldn't worry about this distinction, then this proposal is a no-op on the aspects of the language we should care about, and thus accepting and rejecting have the same effect. (This little analysis only makes sense because the features are so new -- there's no broad re-education to do or back-compat issues.)
- Accepting will make at least one person (John) happy. And I don't note anyone who would become unhappy. More happy people is more better. So I recommend acceptance. :)

Please let us know your thoughts!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240124/933b0828/attachment.html>

From mail at joachim-breitner.de  Wed Jan 24 18:24:25 2024
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 24 Jan 2024 19:24:25 +0100
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
Message-ID: <23fb994ab7c5c9ca63eac19ddcfc40d6055d4ed7.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 24.01.2024 um 17:32 +0000 schrieb Richard Eisenberg:
> - Accepting will make at least one person (John) happy. And I don't note anyone who would become unhappy. More happy people is more better. So I recommend acceptance. :)

unless I am mistaken, this proposal will also un-deprecated
-XPatternSignatures, and give it the semantics I asked for in #119:
allow me to write

   foo :: Monad m => m Int
   foo = do
     list :: String <- return ""
     return $ length list

without treading into type variable territory, having to turn on
ScopedTypeVariables or anything like that. Finally!


So it also makes me a bit happy; in favor.

Cheers,
Joachim


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


From rae at richarde.dev  Wed Jan 24 18:46:58 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 24 Jan 2024 18:46:58 +0000
Subject: [ghc-steering-committee] Proposal #606: small syntax change around
 types in terms; recommendation: vote
Message-ID: <010f018d3ccbfd87-f2b70ca6-0be3-4727-b10f-558dbdbcde60-000000@us-east-2.amazonses.com>

Proposal #606 <https://github.com/ghc-proposals/ghc-proposals/pull/606> has been submitted to the committee, by Vlad.

This proposal makes a tiny change. Suppose we have `f :: forall (x :: Type) -> x -> ...` (this is part of -XRequiredTypeArguments). Then (as proposed) we can write `y = f (type Int -> Int) abs ...`. The `type` keyword here is to signal that what comes is a type: it should be parsed as a type and name-resolved as a type. This might matter if there is, say, a constructor Int in scope. The proposal at hand is whether to accept the above program or to require extra parentheses, thusly: `y = f (type (Int -> Int)) abs ...`. That's it -- that's the entire proposal. (It says we should _not_ accept the former, without parentheses.)

The motivation is to avoid surprising users. Normally when we have `word1 word2 -> word3`, word1 and word2 will associate more closely than the arrow. Yet the first example has `type Int -> Int` where the arrow binds more tightly. Because `type` is a keyword, this is no challenge to parse and is not ambiguous -- it's just perhaps confusing to users.

There was some debate in the proposal, but in my perusal, not a clear indication toward any particular direction. The most rigorous statement I could find is that the new syntax is a subset of the original, and so we can easily reverse this decision later.

I propose we vote on the matter. We have two choices:

1. Original syntax: allow `(type Int -> Int)` as an argument.
2. Amended syntax: require `(type (Int -> Int))` as an argument.

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

My vote: 1.

There are many keywords in Haskell, and we are used to parsing these differently. For example, if we have `f (do x <- blah ...)`, we know quite well that the <- is within the `do`, not the other way around. Ditto `case`: we don't require scrutinees to be parenthesized. I posit that the strangeness some have felt around `(type Int -> Int)` is (understandable) confusion in the face of novelty. But the `type` herald will not be novel forever, and I think we'll enjoy having fewer parentheses in our code in the long run. (I might be arguing for "2 today, then 1 tomorrow". But let's just skip the intermediate step and do 1 now.)

I welcome your opinions and votes. It would be great to conclude this in the next 2 weeks, by Feb 7.

Thanks!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240124/796a825c/attachment-0001.html>

From adam at well-typed.com  Wed Jan 24 20:42:59 2024
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 24 Jan 2024 20:42:59 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <23fb994ab7c5c9ca63eac19ddcfc40d6055d4ed7.camel@joachim-breitner.de>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <23fb994ab7c5c9ca63eac19ddcfc40d6055d4ed7.camel@joachim-breitner.de>
Message-ID: <12323e8d-0b7d-4263-98ff-df88fbd81665@well-typed.com>

I'm also happily in favour, for the reason Joachim articulates.

Adam


On 24/01/2024 18:24, Joachim Breitner wrote:
> Hi,
> 
> Am Mittwoch, dem 24.01.2024 um 17:32 +0000 schrieb Richard Eisenberg:
>> - Accepting will make at least one person (John) happy. And I don't note anyone who would become unhappy. More happy people is more better. So I recommend acceptance. :)
> 
> unless I am mistaken, this proposal will also un-deprecated
> -XPatternSignatures, and give it the semantics I asked for in #119:
> allow me to write
> 
>     foo :: Monad m => m Int
>     foo = do
>       list :: String <- return ""
>       return $ length list
> 
> without treading into type variable territory, having to turn on
> ScopedTypeVariables or anything like that. Finally!
> 
> 
> So it also makes me a bit happy; in favor.
> 
> Cheers,
> Joachim
> 
> 

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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From moritz.angermann at gmail.com  Thu Jan 25 06:06:27 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 25 Jan 2024 14:06:27 +0800
Subject: [ghc-steering-committee] Proposal #612: Change semantics of -fhpc
 to not accumulate data over multiple runs, rec: accept
Message-ID: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>

Dear Committee members,

In Proposal #612 <https://github.com/ghc-proposals/ghc-proposals/pull/612>,
David Binder suggests changing the semantics from `-fhpc` to auto-ingest
existing .tix files for accumulation, towards _not_ auto-ingesting them and
instead overwriting
the .tix file with the coverage of the latest run.

I agree with his assessment that the current behaviour easily leads to
unexpected surprises. He suggests adding a flag --read-tix-file= to control
this behaviour and defaulting that to _no_, with a grace and
deprecation period prior informing the user that the currently accumulating
feature will change in a future GHC release.

Adding the flag to control this behaviour is fairly uncontroversial I hope,
however I'd like you to. Weight in on the default. Should we change the
default behaviour, or only add the flag?

I'd recommend changing the default to --read-tix-file=no after a
deprecation period.

Best,
 Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/dfe826c4/attachment.html>

From moritz.angermann at gmail.com  Thu Jan 25 06:07:34 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 25 Jan 2024 14:07:34 +0800
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <12323e8d-0b7d-4263-98ff-df88fbd81665@well-typed.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <23fb994ab7c5c9ca63eac19ddcfc40d6055d4ed7.camel@joachim-breitner.de>
 <12323e8d-0b7d-4263-98ff-df88fbd81665@well-typed.com>
Message-ID: <CAKfdd-zewu2v+TcV1JGJv=+E-S1FZiOTG9wrM9EPGvsrxuDABw@mail.gmail.com>

As this is guarded behind a language extension and as such should not
impact any existing code. I'm happy to see this change.

On Thu, 25 Jan 2024 at 04:43, Adam Gundry <adam at well-typed.com> wrote:

> I'm also happily in favour, for the reason Joachim articulates.
>
> Adam
>
>
> On 24/01/2024 18:24, Joachim Breitner wrote:
> > Hi,
> >
> > Am Mittwoch, dem 24.01.2024 um 17:32 +0000 schrieb Richard Eisenberg:
> >> - Accepting will make at least one person (John) happy. And I don't
> note anyone who would become unhappy. More happy people is more better. So
> I recommend acceptance. :)
> >
> > unless I am mistaken, this proposal will also un-deprecated
> > -XPatternSignatures, and give it the semantics I asked for in #119:
> > allow me to write
> >
> >     foo :: Monad m => m Int
> >     foo = do
> >       list :: String <- return ""
> >       return $ length list
> >
> > without treading into type variable territory, having to turn on
> > ScopedTypeVariables or anything like that. Finally!
> >
> >
> > So it also makes me a bit happy; in favor.
> >
> > Cheers,
> > Joachim
> >
> >
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/6bae7486/attachment.html>

From moritz.angermann at gmail.com  Thu Jan 25 06:14:27 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 25 Jan 2024 14:14:27 +0800
Subject: [ghc-steering-committee] Proposal #606: small syntax change
 around types in terms; recommendation: vote
In-Reply-To: <010f018d3ccbfd87-f2b70ca6-0be3-4727-b10f-558dbdbcde60-000000@us-east-2.amazonses.com>
References: <010f018d3ccbfd87-f2b70ca6-0be3-4727-b10f-558dbdbcde60-000000@us-east-2.amazonses.com>
Message-ID: <CAKfdd-xmD1fGLvy_PytKqk0boeFx1+zVfB+gsncRBdQLBGw4jw@mail.gmail.com>

Maybe I'm misreading this, but this can potentially break existing code,
can it not?

On Thu, 25 Jan 2024 at 02:47, Richard Eisenberg <rae at richarde.dev> wrote:

> Proposal #606 <https://github.com/ghc-proposals/ghc-proposals/pull/606> has
> been submitted to the committee, by Vlad.
>
> This proposal makes a tiny change. Suppose we have `f :: forall (x ::
> Type) -> x -> ...` (this is part of -XRequiredTypeArguments). Then (as
> proposed) we can write `y = f (type Int -> Int) abs ...`. The `type`
> keyword here is to signal that what comes is a type: it should be parsed as
> a type and name-resolved as a type. This might matter if there is, say, a
> constructor Int in scope. The proposal at hand is whether to accept the
> above program or to require extra parentheses, thusly: `y = f (type (Int ->
> Int)) abs ...`. That's it -- that's the entire proposal. (It says we should
> _not_ accept the former, without parentheses.)
>
> The motivation is to avoid surprising users. Normally when we have `word1
> word2 -> word3`, word1 and word2 will associate more closely than the
> arrow. Yet the first example has `type Int -> Int` where the arrow binds
> more tightly. Because `type` is a keyword, this is no challenge to parse
> and is not ambiguous -- it's just perhaps confusing to users.
>
> There was some debate in the proposal, but in my perusal, not a clear
> indication toward any particular direction. The most rigorous statement I
> could find is that the new syntax is a subset of the original, and so we
> can easily reverse this decision later.
>
> I propose we vote on the matter. We have two choices:
>
> 1. Original syntax: allow `(type Int -> Int)` as an argument.
> 2. Amended syntax: require `(type (Int -> Int))` as an argument.
>
> --------------------------------
>
> My vote: 1.
>
> There are many keywords in Haskell, and we are used to parsing these
> differently. For example, if we have `f (do x <- blah ...)`, we know quite
> well that the <- is within the `do`, not the other way around. Ditto
> `case`: we don't require scrutinees to be parenthesized. I posit that the
> strangeness some have felt around `(type Int -> Int)` is (understandable)
> confusion in the face of novelty. But the `type` herald will not be novel
> forever, and I think we'll enjoy having fewer parentheses in our code in
> the long run. (I might be arguing for "2 today, then 1 tomorrow". But let's
> just skip the intermediate step and do 1 now.)
>
> I welcome your opinions and votes. It would be great to conclude this in
> the next 2 weeks, by Feb 7.
>
> Thanks!
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/7e39afc3/attachment-0001.html>

From moritz.angermann at gmail.com  Thu Jan 25 06:18:26 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 25 Jan 2024 14:18:26 +0800
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAGwnsnmz21QTwKFc_9ANL8=BvFXer9ZPD9g_oaupWUo8NyJUiw@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
 <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
 <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>
 <CAJKmMz8=DGDcu9WeXe=vQtPGqjk+DnedB1KtiWARzeQrQPTang@mail.gmail.com>
 <010f018d3bcc309a-a9101718-cd2b-4554-a4a3-e1ef8bd91794-000000@us-east-2.amazonses.com>
 <CAJKmMz-OVmHSSYcR1gu-68-E2iPBEvKE1SornN1O6NAxwKgDEA@mail.gmail.com>
 <CAGwnsnmz21QTwKFc_9ANL8=BvFXer9ZPD9g_oaupWUo8NyJUiw@mail.gmail.com>
Message-ID: <CAKfdd-y+sYPf0DuJpDMp89uqSSrF+1QX_i68PdgOSOH-uS+RTg@mail.gmail.com>

I'll have to recuse myself from this, as much of this is currently going
above my head. My overall understanding is that
this mostly relaxes what we accept, and therefore won't break existing code?

Best,
 Moritz

On Thu, 25 Jan 2024 at 00:39, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> On Wed, 24 Jan 2024 at 16:39, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Do newtypes make a difference?  E.g      let N x = e in ...
>> where N is the data contructor of a newtype?
>>
>
> I don't think it has too. So for the moment, I vote to stick to the
> current proposal and consider this like all lazy non-variable patterns:
> must be unrestricted.
>
> I suspect that there's a possible refinement where we say that a happy
> pattern is either:
> - A variable
> - Strict
> - A newtype constructor where the inner pattern is happy.
>
> (then if pat is an unhappy pattern, `let pat` must be unrestricted).
>
> But I don't think I'm quite ready to go there for the time being, and
> that'll be a backward compatible change if we change our mind.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/9ba5d169/attachment.html>

From arnaud.spiwack at tweag.io  Thu Jan 25 08:01:21 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 25 Jan 2024 09:01:21 +0100
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAKfdd-y+sYPf0DuJpDMp89uqSSrF+1QX_i68PdgOSOH-uS+RTg@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
 <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
 <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>
 <CAJKmMz8=DGDcu9WeXe=vQtPGqjk+DnedB1KtiWARzeQrQPTang@mail.gmail.com>
 <010f018d3bcc309a-a9101718-cd2b-4554-a4a3-e1ef8bd91794-000000@us-east-2.amazonses.com>
 <CAJKmMz-OVmHSSYcR1gu-68-E2iPBEvKE1SornN1O6NAxwKgDEA@mail.gmail.com>
 <CAGwnsnmz21QTwKFc_9ANL8=BvFXer9ZPD9g_oaupWUo8NyJUiw@mail.gmail.com>
 <CAKfdd-y+sYPf0DuJpDMp89uqSSrF+1QX_i68PdgOSOH-uS+RTg@mail.gmail.com>
Message-ID: <CAGwnsn=pYEOxgc0=cBQ2gTFS+JjVJymhJVCq_NsvnAZ6-2=_hw@mail.gmail.com>

Moritz: there's one breakage introduced (but only for users of LinearTypes,
which is considered experimental), namely that LinearTypes is proposed to
now imply MonoLocalBinds.

On Thu, 25 Jan 2024 at 07:18, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> I'll have to recuse myself from this, as much of this is currently going
> above my head. My overall understanding is that
> this mostly relaxes what we accept, and therefore won't break existing
> code?
>
> Best,
>  Moritz
>
> On Thu, 25 Jan 2024 at 00:39, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> On Wed, 24 Jan 2024 at 16:39, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Do newtypes make a difference?  E.g      let N x = e in ...
>>> where N is the data contructor of a newtype?
>>>
>>
>> I don't think it has too. So for the moment, I vote to stick to the
>> current proposal and consider this like all lazy non-variable patterns:
>> must be unrestricted.
>>
>> I suspect that there's a possible refinement where we say that a happy
>> pattern is either:
>> - A variable
>> - Strict
>> - A newtype constructor where the inner pattern is happy.
>>
>> (then if pat is an unhappy pattern, `let pat` must be unrestricted).
>>
>> But I don't think I'm quite ready to go there for the time being, and
>> that'll be a backward compatible change if we change our mind.
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/c4221622/attachment.html>

From moritz.angermann at gmail.com  Thu Jan 25 08:07:19 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 25 Jan 2024 16:07:19 +0800
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAGwnsn=pYEOxgc0=cBQ2gTFS+JjVJymhJVCq_NsvnAZ6-2=_hw@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
 <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
 <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>
 <CAJKmMz8=DGDcu9WeXe=vQtPGqjk+DnedB1KtiWARzeQrQPTang@mail.gmail.com>
 <010f018d3bcc309a-a9101718-cd2b-4554-a4a3-e1ef8bd91794-000000@us-east-2.amazonses.com>
 <CAJKmMz-OVmHSSYcR1gu-68-E2iPBEvKE1SornN1O6NAxwKgDEA@mail.gmail.com>
 <CAGwnsnmz21QTwKFc_9ANL8=BvFXer9ZPD9g_oaupWUo8NyJUiw@mail.gmail.com>
 <CAKfdd-y+sYPf0DuJpDMp89uqSSrF+1QX_i68PdgOSOH-uS+RTg@mail.gmail.com>
 <CAGwnsn=pYEOxgc0=cBQ2gTFS+JjVJymhJVCq_NsvnAZ6-2=_hw@mail.gmail.com>
Message-ID: <CAKfdd-zzjYTKbqdCy7OnZ1+qpag1wdZQghesWL59SEwYTrJ8Zw@mail.gmail.com>

Arnaud, I agree that _we_ consider LinearTypes experimental. I hope we can
get https://github.com/ghc-proposals/ghc-proposals/pull/617 agreed on soon,
so that the compiler has
this knowledge as well. I am however not able to fully comprehend the
technical details of this proposal right and therefore will defer to others
on this!

On Thu, 25 Jan 2024 at 16:01, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Moritz: there's one breakage introduced (but only for users of
> LinearTypes, which is considered experimental), namely that LinearTypes is
> proposed to now imply MonoLocalBinds.
>
> On Thu, 25 Jan 2024 at 07:18, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> I'll have to recuse myself from this, as much of this is currently going
>> above my head. My overall understanding is that
>> this mostly relaxes what we accept, and therefore won't break existing
>> code?
>>
>> Best,
>>  Moritz
>>
>> On Thu, 25 Jan 2024 at 00:39, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> On Wed, 24 Jan 2024 at 16:39, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> Do newtypes make a difference?  E.g      let N x = e in ...
>>>> where N is the data contructor of a newtype?
>>>>
>>>
>>> I don't think it has too. So for the moment, I vote to stick to the
>>> current proposal and consider this like all lazy non-variable patterns:
>>> must be unrestricted.
>>>
>>> I suspect that there's a possible refinement where we say that a happy
>>> pattern is either:
>>> - A variable
>>> - Strict
>>> - A newtype constructor where the inner pattern is happy.
>>>
>>> (then if pat is an unhappy pattern, `let pat` must be unrestricted).
>>>
>>> But I don't think I'm quite ready to go there for the time being, and
>>> that'll be a backward compatible change if we change our mind.
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/5b1ec667/attachment-0001.html>

From adam at well-typed.com  Thu Jan 25 08:25:17 2024
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 25 Jan 2024 08:25:17 +0000
Subject: [ghc-steering-committee] Proposal #606: small syntax change
 around types in terms; recommendation: vote
In-Reply-To: <CAKfdd-xmD1fGLvy_PytKqk0boeFx1+zVfB+gsncRBdQLBGw4jw@mail.gmail.com>
References: <010f018d3ccbfd87-f2b70ca6-0be3-4727-b10f-558dbdbcde60-000000@us-east-2.amazonses.com>
 <CAKfdd-xmD1fGLvy_PytKqk0boeFx1+zVfB+gsncRBdQLBGw4jw@mail.gmail.com>
Message-ID: <77bdd4eb-b83c-402c-a30c-a5bb96385fb2@well-typed.com>

On 25/01/2024 06:14, Moritz Angermann wrote:
> Maybe I'm misreading this, but this can potentially break existing code, 
> can it not?

I don't think this has been released yet, because RequiredTypeArguments 
is coming as part of GHC 9.10, and the fork is due in about a month. So 
there's no existing code to break and we can freely choose at this 
point, provided the decision is made in good time. Of course if 9.10 
ships with option 1 and we later switch to option 2, that would be a 
breaking change. But it looks like HEAD might currently have option 2 
implemented anyway?

As to the proposal overall, I'm rather on the fence.

Adam



> On Thu, 25 Jan 2024 at 02:47, Richard Eisenberg <rae at richarde.dev 
> <mailto:rae at richarde.dev>> wrote:
> 
>     Proposal #606
>     <https://github.com/ghc-proposals/ghc-proposals/pull/606> has been
>     submitted to the committee, by Vlad.
> 
>     This proposal makes a tiny change. Suppose we have `f :: forall (x
>     :: Type) -> x -> ...` (this is part of -XRequiredTypeArguments).
>     Then (as proposed) we can write `y = f (type Int -> Int) abs ...`.
>     The `type` keyword here is to signal that what comes is a type: it
>     should be parsed as a type and name-resolved as a type. This might
>     matter if there is, say, a constructor Int in scope. The proposal at
>     hand is whether to accept the above program or to require extra
>     parentheses, thusly: `y = f (type (Int -> Int)) abs ...`. That's it
>     -- that's the entire proposal. (It says we should _not_ accept the
>     former, without parentheses.)
> 
>     The motivation is to avoid surprising users. Normally when we have
>     `word1 word2 -> word3`, word1 and word2 will associate more closely
>     than the arrow. Yet the first example has `type Int -> Int` where
>     the arrow binds more tightly. Because `type` is a keyword, this is
>     no challenge to parse and is not ambiguous -- it's just perhaps
>     confusing to users.
> 
>     There was some debate in the proposal, but in my perusal, not a
>     clear indication toward any particular direction. The most rigorous
>     statement I could find is that the new syntax is a subset of the
>     original, and so we can easily reverse this decision later.
> 
>     I propose we vote on the matter. We have two choices:
> 
>     1. Original syntax: allow `(type Int -> Int)` as an argument.
>     2. Amended syntax: require `(type (Int -> Int))` as an argument.
> 
>     --------------------------------
> 
>     My vote: 1.
> 
>     There are many keywords in Haskell, and we are used to parsing these
>     differently. For example, if we have `f (do x <- blah ...)`, we know
>     quite well that the <- is within the `do`, not the other way around.
>     Ditto `case`: we don't require scrutinees to be parenthesized. I
>     posit that the strangeness some have felt around `(type Int -> Int)`
>     is (understandable) confusion in the face of novelty. But the `type`
>     herald will not be novel forever, and I think we'll enjoy having
>     fewer parentheses in our code in the long run. (I might be arguing
>     for "2 today, then 1 tomorrow". But let's just skip the intermediate
>     step and do 1 now.)
> 
>     I welcome your opinions and votes. It would be great to conclude
>     this in the next 2 weeks, by Feb 7.
> 
>     Thanks!
>     Richard


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From arnaud.spiwack at tweag.io  Thu Jan 25 08:25:59 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 25 Jan 2024 09:25:59 +0100
Subject: [ghc-steering-committee] Proposal #606: small syntax change
 around types in terms; recommendation: vote
In-Reply-To: <CAKfdd-xmD1fGLvy_PytKqk0boeFx1+zVfB+gsncRBdQLBGw4jw@mail.gmail.com>
References: <010f018d3ccbfd87-f2b70ca6-0be3-4727-b10f-558dbdbcde60-000000@us-east-2.amazonses.com>
 <CAKfdd-xmD1fGLvy_PytKqk0boeFx1+zVfB+gsncRBdQLBGw4jw@mail.gmail.com>
Message-ID: <CAGwnsnmi2uRHhAqEMu8N8jUNzxe+YEe23Ewn3=zvGJhbogDkwA@mail.gmail.com>

I keep going back and forth. But

I vote 1

On the grounds that:
- The extra parentheses would almost always be needed, 2 is probably an
unreasonable amount of syntactic noise
- We write `type Maybe a = …` not `type (Maybe a) = …`. So there's more
symmetry with the declaration in 1.

Yet, like Simon and Joachim, it took me a second to parse `f (type Maybe
Int)` correctly.

On Thu, 25 Jan 2024 at 07:14, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Maybe I'm misreading this, but this can potentially break existing code,
> can it not?
>
> On Thu, 25 Jan 2024 at 02:47, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> Proposal #606 <https://github.com/ghc-proposals/ghc-proposals/pull/606> has
>> been submitted to the committee, by Vlad.
>>
>> This proposal makes a tiny change. Suppose we have `f :: forall (x ::
>> Type) -> x -> ...` (this is part of -XRequiredTypeArguments). Then (as
>> proposed) we can write `y = f (type Int -> Int) abs ...`. The `type`
>> keyword here is to signal that what comes is a type: it should be parsed as
>> a type and name-resolved as a type. This might matter if there is, say, a
>> constructor Int in scope. The proposal at hand is whether to accept the
>> above program or to require extra parentheses, thusly: `y = f (type (Int ->
>> Int)) abs ...`. That's it -- that's the entire proposal. (It says we should
>> _not_ accept the former, without parentheses.)
>>
>> The motivation is to avoid surprising users. Normally when we have `word1
>> word2 -> word3`, word1 and word2 will associate more closely than the
>> arrow. Yet the first example has `type Int -> Int` where the arrow binds
>> more tightly. Because `type` is a keyword, this is no challenge to parse
>> and is not ambiguous -- it's just perhaps confusing to users.
>>
>> There was some debate in the proposal, but in my perusal, not a clear
>> indication toward any particular direction. The most rigorous statement I
>> could find is that the new syntax is a subset of the original, and so we
>> can easily reverse this decision later.
>>
>> I propose we vote on the matter. We have two choices:
>>
>> 1. Original syntax: allow `(type Int -> Int)` as an argument.
>> 2. Amended syntax: require `(type (Int -> Int))` as an argument.
>>
>> --------------------------------
>>
>> My vote: 1.
>>
>> There are many keywords in Haskell, and we are used to parsing these
>> differently. For example, if we have `f (do x <- blah ...)`, we know quite
>> well that the <- is within the `do`, not the other way around. Ditto
>> `case`: we don't require scrutinees to be parenthesized. I posit that the
>> strangeness some have felt around `(type Int -> Int)` is (understandable)
>> confusion in the face of novelty. But the `type` herald will not be novel
>> forever, and I think we'll enjoy having fewer parentheses in our code in
>> the long run. (I might be arguing for "2 today, then 1 tomorrow". But let's
>> just skip the intermediate step and do 1 now.)
>>
>> I welcome your opinions and votes. It would be great to conclude this in
>> the next 2 weeks, by Feb 7.
>>
>> Thanks!
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/5dc5397f/attachment.html>

From adam at well-typed.com  Thu Jan 25 09:13:26 2024
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 25 Jan 2024 09:13:26 +0000
Subject: [ghc-steering-committee] Please review #617: Add -experimental flag,
	Shepherd: Simon M
Message-ID: <7a9c8bb6-deec-49c5-9898-3701917ff2d9@well-typed.com>

Dear Committee,

Moritz proposes to add a new flag, -experimental, to guard experimental 
features:

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

https://github.com/angerman/ghc-proposals/blob/std-experimental/proposals/0000-std-experimental.rst

I’d like to nominate Simon Marlow as the shepherd.

Please guide us to a conclusion as outlined in
https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

From arnaud.spiwack at tweag.io  Thu Jan 25 10:34:46 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 25 Jan 2024 11:34:46 +0100
Subject: [ghc-steering-committee] Proposal #612: Change semantics of
 -fhpc to not accumulate data over multiple runs, rec: accept
In-Reply-To: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
References: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
Message-ID: <CAGwnsn=YkEtx3xSPbjvm9bde2hd7kfzwptKnoxqUBhVRuAC3FA@mail.gmail.com>

The proposed change seems sensible. At least the argument is convincing. I
don't use hpc myself, so I don't have an actual design opinion besides
that. So I vote (weakly) for the proposed new default.

Is a deprecation period necessary? Or even useful (how do we signal the
upcoming change in default, and how do we expect people would act on it)?

On Thu, 25 Jan 2024 at 07:06, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Dear Committee members,
>
> In Proposal #612 <https://github.com/ghc-proposals/ghc-proposals/pull/612>,
> David Binder suggests changing the semantics from `-fhpc` to auto-ingest
> existing .tix files for accumulation, towards _not_ auto-ingesting them
> and instead overwriting
> the .tix file with the coverage of the latest run.
>
> I agree with his assessment that the current behaviour easily leads to
> unexpected surprises. He suggests adding a flag --read-tix-file= to control
> this behaviour and defaulting that to _no_, with a grace and
> deprecation period prior informing the user that the currently accumulating
> feature will change in a future GHC release.
>
> Adding the flag to control this behaviour is fairly uncontroversial I
> hope, however I'd like you to. Weight in on the default. Should we change
> the default behaviour, or only add the flag?
>
> I'd recommend changing the default to --read-tix-file=no after a
> deprecation period.
>
> Best,
>  Moritz
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/e030723f/attachment-0001.html>

From moritz.angermann at gmail.com  Thu Jan 25 10:49:31 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 25 Jan 2024 18:49:31 +0800
Subject: [ghc-steering-committee] Proposal #612: Change semantics of
 -fhpc to not accumulate data over multiple runs, rec: accept
In-Reply-To: <CAGwnsn=YkEtx3xSPbjvm9bde2hd7kfzwptKnoxqUBhVRuAC3FA@mail.gmail.com>
References: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
 <CAGwnsn=YkEtx3xSPbjvm9bde2hd7kfzwptKnoxqUBhVRuAC3FA@mail.gmail.com>
Message-ID: <CAKfdd-zTz0Ko8pm+PpW4uH+GoOBxdy2svt2A53yFCmhQzhxXXw@mail.gmail.com>

Here's my rationale for a deprecation period.

Someone who uses hpc, might rely on the accumulating behaviour.  They need
a way to be informed about the upcoming change, otherwise they won't know
that they need to pass a new flag going forward (and they can
even start doing that at that point to be defensive). I also hope the
deprecation note would show up in automated tooling, which can then be
proactively adjusted.

To me the compiler is _the_ interface to the end user.  Chances that
someone reads the proposals, GHC changelog are very low. Chances someone
reads the user guide in detail for each GHC release are low as well,
only after the fact, if someone broke will someone start trying to figure
out why something broke. At that point, I think we've lost. They are
frustrated already that something they knew worked just broke.

So to me the deprecation note is basically the signage towards the end
user that uses hpc, that they will need to adjust their ghc invocation if
they rely on the current behaviour, and also a courtesy heads up that the
behaviour
they might rely on changes, _and_ how to adjust and get their old behaviour
(they may need/rely on) back.

To address your two points in detail:
> Is a deprecation period necessary? Or even useful (how do we signal the
upcoming change in default, and how do we expect people would act on it)?
- As the flag currently does not exist, call GHC with hpc without the new
flag will issue a warning. (e.g. current users will be informed).
- The warning message will let the user know what to pass to ghc to retain
the old (current) behaviour, or opt in to the new (future current)
behaviour, depending on their needs.

If we did neither, the user would at some point just notice an existing
workflow magically stopped or in this case even worse, the silent
aggregation of .tix data would stop, and they
might _assume_ the data was the aggregate but it wasn't. A silent change in
default behaviour would be rather painful to notice, debug, and rectify for
users. At least that's my expectation.
(And I know I personally would be furious if a compiler pulled that on me).

Best,
 Moritz

On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> The proposed change seems sensible. At least the argument is convincing. I
> don't use hpc myself, so I don't have an actual design opinion besides
> that. So I vote (weakly) for the proposed new default.
>
> Is a deprecation period necessary? Or even useful (how do we signal the
> upcoming change in default, and how do we expect people would act on it)?
>
> On Thu, 25 Jan 2024 at 07:06, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> Dear Committee members,
>>
>> In Proposal #612
>> <https://github.com/ghc-proposals/ghc-proposals/pull/612>, David Binder
>> suggests changing the semantics from `-fhpc` to auto-ingest
>> existing .tix files for accumulation, towards _not_ auto-ingesting them
>> and instead overwriting
>> the .tix file with the coverage of the latest run.
>>
>> I agree with his assessment that the current behaviour easily leads to
>> unexpected surprises. He suggests adding a flag --read-tix-file= to control
>> this behaviour and defaulting that to _no_, with a grace and
>> deprecation period prior informing the user that the currently accumulating
>> feature will change in a future GHC release.
>>
>> Adding the flag to control this behaviour is fairly uncontroversial I
>> hope, however I'd like you to. Weight in on the default. Should we change
>> the default behaviour, or only add the flag?
>>
>> I'd recommend changing the default to --read-tix-file=no after a
>> deprecation period.
>>
>> Best,
>>  Moritz
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/5f5633e4/attachment.html>

From simon.peytonjones at gmail.com  Thu Jan 25 12:07:22 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 25 Jan 2024 12:07:22 +0000
Subject: [ghc-steering-committee] Fwd: Proposal #606: small syntax change
 around types in terms; recommendation: vote
In-Reply-To: <010f018d3ccbfd87-f2b70ca6-0be3-4727-b10f-558dbdbcde60-000000@us-east-2.amazonses.com>
References: <010f018d3ccbfd87-f2b70ca6-0be3-4727-b10f-558dbdbcde60-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz9MVHJWyipdWo1HxGcDG+fSXOA-iVkTQVfUf-br7y19qA@mail.gmail.com>

I vote (2), fairly strongly

Remember this comment from Vlad:

@phadej <https://github.com/phadej> For what it's worth, this was my
> initial thinking when I put ktype there, so past me agrees with you. What
> changed my opinion is that two years later (i.e. now) I looked at the
> examples like *fn (type Int -> [a])* and had to double check the
> specification if it was supposed to be fn ((type Int) -> [a]) or fn (type
> (Int -> [a])).


The point is that the `type` namespace changer can appear *deep within a
type*.  It's not like "@"!    For exmaple
fn ((type K) -> [a])
makes perfect sense.  fn has a required type argument, but in the
(type K) *sub-part
*of the type do we switch to the type namespace.  (Maybe K is in scope also
as a data constructor.)  Without the parens, do you really want to wonder
about how this parses?
fn (type K -> [a])

I prefer code that is slightly longer, but much clearer, than saving two
characters but requiring reference to the user manual to parse.

Let's make it simple and unambiguous for now.  If it seems painful in
practice we can debate liberalising it.

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/f0d81ed8/attachment.html>

From reisenberg at janestreet.com  Thu Jan 25 18:19:43 2024
From: reisenberg at janestreet.com (Richard Eisenberg)
Date: Thu, 25 Jan 2024 13:19:43 -0500
Subject: [ghc-steering-committee] Fwd: Proposal #606: small syntax
 change around types in terms; recommendation: vote
In-Reply-To: <CAJKmMz9MVHJWyipdWo1HxGcDG+fSXOA-iVkTQVfUf-br7y19qA@mail.gmail.com>
References: <010f018d3ccbfd87-f2b70ca6-0be3-4727-b10f-558dbdbcde60-000000@us-east-2.amazonses.com>
 <CAJKmMz9MVHJWyipdWo1HxGcDG+fSXOA-iVkTQVfUf-br7y19qA@mail.gmail.com>
Message-ID: <CALkkMoRAnO=-qymD5B9-011YjY7EBoBtGYpBsw8nrQ17NL=fKg@mail.gmail.com>

I remain unmoved by Simon's example. The status quo is already simple:
`type` extends as far to the right as possible. Just like \. And just like
`do`, `else`, and `in`.

The hope is that people using this will tend to avoid punning, and so the
matter will be moot, anyway.

Richard

On Thu, Jan 25, 2024 at 7:08 AM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I vote (2), fairly strongly
>
> Remember this comment from Vlad:
>
> @phadej <https://github.com/phadej> For what it's worth, this was my
>> initial thinking when I put ktype there, so past me agrees with you.
>> What changed my opinion is that two years later (i.e. now) I looked at the
>> examples like *fn (type Int -> [a])* and had to double check the
>> specification if it was supposed to be fn ((type Int) -> [a]) or fn
>> (type (Int -> [a])).
>
>
> The point is that the `type` namespace changer can appear *deep within a
> type*.  It's not like "@"!    For exmaple
> fn ((type K) -> [a])
> makes perfect sense.  fn has a required type argument, but in the (type K) *sub-part
> *of the type do we switch to the type namespace.  (Maybe K is in scope
> also as a data constructor.)  Without the parens, do you really want to
> wonder about how this parses?
> fn (type K -> [a])
>
> I prefer code that is slightly longer, but much clearer, than saving two
> characters but requiring reference to the user manual to parse.
>
> Let's make it simple and unambiguous for now.  If it seems painful in
> practice we can debate liberalising it.
>
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/865b0296/attachment.html>

From reisenberg at janestreet.com  Thu Jan 25 18:20:47 2024
From: reisenberg at janestreet.com (Richard Eisenberg)
Date: Thu, 25 Jan 2024 13:20:47 -0500
Subject: [ghc-steering-committee] Proposal #612: Change semantics of
 -fhpc to not accumulate data over multiple runs, rec: accept
In-Reply-To: <CAKfdd-zTz0Ko8pm+PpW4uH+GoOBxdy2svt2A53yFCmhQzhxXXw@mail.gmail.com>
References: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
 <CAGwnsn=YkEtx3xSPbjvm9bde2hd7kfzwptKnoxqUBhVRuAC3FA@mail.gmail.com>
 <CAKfdd-zTz0Ko8pm+PpW4uH+GoOBxdy2svt2A53yFCmhQzhxXXw@mail.gmail.com>
Message-ID: <CALkkMoRNmFFB_htfT-f99B2h-aVsMm=TpQGVDZnBc09-1fF8rg@mail.gmail.com>

This is an area in which I'm uneducated. I'll abstain, unless we feel like
there is enough contention here that it's worth time educating myself.

Thanks for driving this forward, Moritz.

Richard

On Thu, Jan 25, 2024 at 5:50 AM Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Here's my rationale for a deprecation period.
>
> Someone who uses hpc, might rely on the accumulating behaviour.  They need
> a way to be informed about the upcoming change, otherwise they won't know
> that they need to pass a new flag going forward (and they can
> even start doing that at that point to be defensive). I also hope the
> deprecation note would show up in automated tooling, which can then be
> proactively adjusted.
>
> To me the compiler is _the_ interface to the end user.  Chances that
> someone reads the proposals, GHC changelog are very low. Chances someone
> reads the user guide in detail for each GHC release are low as well,
> only after the fact, if someone broke will someone start trying to figure
> out why something broke. At that point, I think we've lost. They are
> frustrated already that something they knew worked just broke.
>
> So to me the deprecation note is basically the signage towards the end
> user that uses hpc, that they will need to adjust their ghc invocation if
> they rely on the current behaviour, and also a courtesy heads up that the
> behaviour
> they might rely on changes, _and_ how to adjust and get their old
> behaviour (they may need/rely on) back.
>
> To address your two points in detail:
> > Is a deprecation period necessary? Or even useful (how do we signal the
> upcoming change in default, and how do we expect people would act on it)?
> - As the flag currently does not exist, call GHC with hpc without the new
> flag will issue a warning. (e.g. current users will be informed).
> - The warning message will let the user know what to pass to ghc to retain
> the old (current) behaviour, or opt in to the new (future current)
> behaviour, depending on their needs.
>
> If we did neither, the user would at some point just notice an existing
> workflow magically stopped or in this case even worse, the silent
> aggregation of .tix data would stop, and they
> might _assume_ the data was the aggregate but it wasn't. A silent change
> in default behaviour would be rather painful to notice, debug, and rectify
> for users. At least that's my expectation.
> (And I know I personally would be furious if a compiler pulled that on me).
>
> Best,
>  Moritz
>
> On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> The proposed change seems sensible. At least the argument is convincing.
>> I don't use hpc myself, so I don't have an actual design opinion besides
>> that. So I vote (weakly) for the proposed new default.
>>
>> Is a deprecation period necessary? Or even useful (how do we signal the
>> upcoming change in default, and how do we expect people would act on it)?
>>
>> On Thu, 25 Jan 2024 at 07:06, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> Dear Committee members,
>>>
>>> In Proposal #612
>>> <https://github.com/ghc-proposals/ghc-proposals/pull/612>, David Binder
>>> suggests changing the semantics from `-fhpc` to auto-ingest
>>> existing .tix files for accumulation, towards _not_ auto-ingesting them
>>> and instead overwriting
>>> the .tix file with the coverage of the latest run.
>>>
>>> I agree with his assessment that the current behaviour easily leads to
>>> unexpected surprises. He suggests adding a flag --read-tix-file= to control
>>> this behaviour and defaulting that to _no_, with a grace and
>>> deprecation period prior informing the user that the currently accumulating
>>> feature will change in a future GHC release.
>>>
>>> Adding the flag to control this behaviour is fairly uncontroversial I
>>> hope, however I'd like you to. Weight in on the default. Should we change
>>> the default behaviour, or only add the flag?
>>>
>>> I'd recommend changing the default to --read-tix-file=no after a
>>> deprecation period.
>>>
>>> Best,
>>>  Moritz
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/dbcb4027/attachment.html>

From arnaud.spiwack at tweag.io  Fri Jan 26 07:49:31 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 26 Jan 2024 08:49:31 +0100
Subject: [ghc-steering-committee] Proposal #612: Change semantics of
 -fhpc to not accumulate data over multiple runs, rec: accept
In-Reply-To: <CAKfdd-zTz0Ko8pm+PpW4uH+GoOBxdy2svt2A53yFCmhQzhxXXw@mail.gmail.com>
References: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
 <CAGwnsn=YkEtx3xSPbjvm9bde2hd7kfzwptKnoxqUBhVRuAC3FA@mail.gmail.com>
 <CAKfdd-zTz0Ko8pm+PpW4uH+GoOBxdy2svt2A53yFCmhQzhxXXw@mail.gmail.com>
Message-ID: <CAGwnsnndE-P2i0wf+vyH=K=OO=w4s3RQx3Gw0wjkTcftgw43Mw@mail.gmail.com>

On Thu, 25 Jan 2024 at 11:49, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> To address your two points in detail:
> > Is a deprecation period necessary? Or even useful (how do we signal the
> upcoming change in default, and how do we expect people would act on it)?
> - As the flag currently does not exist, call GHC with hpc without the new
> flag will issue a warning. (e.g. current users will be informed).
> - The warning message will let the user know what to pass to ghc to retain
> the old (current) behaviour, or opt in to the new (future current)
> behaviour, depending on their needs.
>
> If we did neither, the user would at some point just notice an existing
> workflow magically stopped or in this case even worse, the silent
> aggregation of .tix data would stop, and they
> might _assume_ the data was the aggregate but it wasn't. A silent change
> in default behaviour would be rather painful to notice, debug, and rectify
> for users. At least that's my expectation.
> (And I know I personally would be furious if a compiler pulled that on me).
>

My guess as to what will happen: people run hpc in CI, at a place where the
warning isn't an error, the warning won't be seen, and the breakage will
happen all the same. Just a few versions later.

To be clear, I don't really care either way. But I'm suspicious of creating
extra work for maintainers if we don't believe it's going to actually be
useful. There's not enough maintainer time as it is. So I guess my real
question is: why do you think my scenario above is incorrect?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240126/05607a15/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Jan 26 08:03:42 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 26 Jan 2024 09:03:42 +0100
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <CAKfdd-zewu2v+TcV1JGJv=+E-S1FZiOTG9wrM9EPGvsrxuDABw@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <23fb994ab7c5c9ca63eac19ddcfc40d6055d4ed7.camel@joachim-breitner.de>
 <12323e8d-0b7d-4263-98ff-df88fbd81665@well-typed.com>
 <CAKfdd-zewu2v+TcV1JGJv=+E-S1FZiOTG9wrM9EPGvsrxuDABw@mail.gmail.com>
Message-ID: <CAGwnsnnR4B1Ns8MzXUn7Xpy1e5f-=uYQ491z1W6V6Wf77jcQpQ@mail.gmail.com>

Do we envision, maybe, a future with `-XPatternSignature`, in a version
that is incapable of binding and `-XTypeAbstractions`? If so, the split
sounds like a reasonable move. Otherwise, the benefit of the split sounds
rather slim, and it would need to be weighed against the costs and benefits
on the implementation.

On Thu, 25 Jan 2024 at 07:07, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> As this is guarded behind a language extension and as such should not
> impact any existing code. I'm happy to see this change.
>
> On Thu, 25 Jan 2024 at 04:43, Adam Gundry <adam at well-typed.com> wrote:
>
>> I'm also happily in favour, for the reason Joachim articulates.
>>
>> Adam
>>
>>
>> On 24/01/2024 18:24, Joachim Breitner wrote:
>> > Hi,
>> >
>> > Am Mittwoch, dem 24.01.2024 um 17:32 +0000 schrieb Richard Eisenberg:
>> >> - Accepting will make at least one person (John) happy. And I don't
>> note anyone who would become unhappy. More happy people is more better. So
>> I recommend acceptance. :)
>> >
>> > unless I am mistaken, this proposal will also un-deprecated
>> > -XPatternSignatures, and give it the semantics I asked for in #119:
>> > allow me to write
>> >
>> >     foo :: Monad m => m Int
>> >     foo = do
>> >       list :: String <- return ""
>> >       return $ length list
>> >
>> > without treading into type variable territory, having to turn on
>> > ScopedTypeVariables or anything like that. Finally!
>> >
>> >
>> > So it also makes me a bit happy; in favor.
>> >
>> > Cheers,
>> > Joachim
>> >
>> >
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240126/8008ad8c/attachment.html>

From mail at joachim-breitner.de  Fri Jan 26 15:31:00 2024
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 26 Jan 2024 16:31:00 +0100
Subject: [ghc-steering-committee] Secretary of the GHC Steering Committee
In-Reply-To: <cd9d42fd-648f-4450-8271-a3727232dcf6@well-typed.com>
References: <CAJKmMz9d+JncAP8A2VGTwSC8dXuJ1G7hnkqOa7090a+j_xhN-A@mail.gmail.com>
 <CAJKmMz9rRHGfYnFrCa6MokQaTYZ1UNA5AXH3CFTKuwqqwEeGag@mail.gmail.com>
 <60405775-09ee-4f98-9c88-c2f657bb39da@app.fastmail.com>
 <CAGwnsnmm8Cu4Aux-jfvjb1dt58945xAh7P72DmphQt7VsrGBbw@mail.gmail.com>
 <cd9d42fd-648f-4450-8271-a3727232dcf6@well-typed.com>
Message-ID: <17c83eacea1bfcd62368757c85510d49a1b544a0.camel@joachim-breitner.de>

Hi,

Am Montag, dem 22.01.2024 um 20:47 +0000 schrieb Adam Gundry:
> (Joachim, if you have any particular pointers for how to do this, e.g. 
> regarding the specific voting mechanism you've used in previous rounds, 
> that would be welcome.)

because we do this thing where we have a slightly varying committee
size and am happy to take on more good candidates than absolutely
necessary, I did an overly complicated ranked voting system. The email
I sent during the last regular round, with three candidates, had this
section:

%%%%%%%%%%%%%%%%%%%%%%%%%%%

## Voting procedure

We have currently 7 non-expiring members, and our bylaws say we should
have a committee of “roughly 10”, so we can take on all candidates. We
should take on at least two, if possible, else we’d be compelled to do
another round of nominations (the bylaws say that less than 9 members
trigger a call for nomination).

To express our options, we’ll use the following ranked voting. In an
email to me (or all of us, if you want, but _not_ the mailing list),
order the following lines according your order of preference, starting
with your most preferred statement:

AAA joins the committee
BBB joins the committee
CCC joins the committee
Committee has 9 members, two new
Committee has 8 members, one new
Committee has 7 members, no new

Please vote within one week, until Friday, Feb 19th (or at least
briefly ask for an extension).

## Example

For example (using made up names), if you think that all candidates are
good enough to get us up to 9 members, but you’d rather not grow the
committee further except with Donald Duck, then you could write

Donald Duck
Committee has 9 members, two new
Mickey Mouse
Peter Pan
Committee has 8 members, one new
Committee has 7 members, no new

If you want to vote against a certain candidate, put their name _after_
“Committee has 7 members, no new”.

(Yes, maybe a tad complicated, and it would make more sense if we had
more candidates. But I hope you’ll entertain my electorial whims :-)

%%%%%%%%%%%%%%%%%%%%%%%%%%%

But it may just suffice to go for plain approval voting, where every
member says yay or nay, and those approved by a majority are in - up to
you.

Cheers,
Joachim


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


From reisenberg at janestreet.com  Fri Jan 26 15:43:23 2024
From: reisenberg at janestreet.com (Richard Eisenberg)
Date: Fri, 26 Jan 2024 10:43:23 -0500
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds.  Rec: accept
In-Reply-To: <CAGwnsnnR4B1Ns8MzXUn7Xpy1e5f-=uYQ491z1W6V6Wf77jcQpQ@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <23fb994ab7c5c9ca63eac19ddcfc40d6055d4ed7.camel@joachim-breitner.de>
 <12323e8d-0b7d-4263-98ff-df88fbd81665@well-typed.com>
 <CAKfdd-zewu2v+TcV1JGJv=+E-S1FZiOTG9wrM9EPGvsrxuDABw@mail.gmail.com>
 <CAGwnsnnR4B1Ns8MzXUn7Xpy1e5f-=uYQ491z1W6V6Wf77jcQpQ@mail.gmail.com>
Message-ID: <CALkkMoT-vp=PnCE2tzWzfbTY07-tnS2GvBd8MKzCNt_k7d2b5A@mail.gmail.com>

I'm not sure I understand Arnaud's question here: this proposal removes the
binding capability from -XPatternSignatures. I don't think there's an
interaction with -XTypeAbstractions.

On Fri, Jan 26, 2024 at 3:04 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Do we envision, maybe, a future with `-XPatternSignature`, in a version
> that is incapable of binding and `-XTypeAbstractions`? If so, the split
> sounds like a reasonable move. Otherwise, the benefit of the split sounds
> rather slim, and it would need to be weighed against the costs and benefits
> on the implementation.
>
> On Thu, 25 Jan 2024 at 07:07, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> As this is guarded behind a language extension and as such should not
>> impact any existing code. I'm happy to see this change.
>>
>> On Thu, 25 Jan 2024 at 04:43, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> I'm also happily in favour, for the reason Joachim articulates.
>>>
>>> Adam
>>>
>>>
>>> On 24/01/2024 18:24, Joachim Breitner wrote:
>>> > Hi,
>>> >
>>> > Am Mittwoch, dem 24.01.2024 um 17:32 +0000 schrieb Richard Eisenberg:
>>> >> - Accepting will make at least one person (John) happy. And I don't
>>> note anyone who would become unhappy. More happy people is more better. So
>>> I recommend acceptance. :)
>>> >
>>> > unless I am mistaken, this proposal will also un-deprecated
>>> > -XPatternSignatures, and give it the semantics I asked for in #119:
>>> > allow me to write
>>> >
>>> >     foo :: Monad m => m Int
>>> >     foo = do
>>> >       list :: String <- return ""
>>> >       return $ length list
>>> >
>>> > without treading into type variable territory, having to turn on
>>> > ScopedTypeVariables or anything like that. Finally!
>>> >
>>> >
>>> > So it also makes me a bit happy; in favor.
>>> >
>>> > Cheers,
>>> > Joachim
>>> >
>>> >
>>>
>>> --
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>>
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240126/f534e18f/attachment.html>

From arnaud.spiwack at tweag.io  Fri Jan 26 16:09:39 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 26 Jan 2024 17:09:39 +0100
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <CALkkMoT-vp=PnCE2tzWzfbTY07-tnS2GvBd8MKzCNt_k7d2b5A@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <23fb994ab7c5c9ca63eac19ddcfc40d6055d4ed7.camel@joachim-breitner.de>
 <12323e8d-0b7d-4263-98ff-df88fbd81665@well-typed.com>
 <CAKfdd-zewu2v+TcV1JGJv=+E-S1FZiOTG9wrM9EPGvsrxuDABw@mail.gmail.com>
 <CAGwnsnnR4B1Ns8MzXUn7Xpy1e5f-=uYQ491z1W6V6Wf77jcQpQ@mail.gmail.com>
 <CALkkMoT-vp=PnCE2tzWzfbTY07-tnS2GvBd8MKzCNt_k7d2b5A@mail.gmail.com>
Message-ID: <CAGwnsnn=J9z-yTpHC8eSd4tgacx64OErKXuFaWe=Bv9c=+LKyA@mail.gmail.com>

What I was asking was whether we imagined that `-XPatternSignatures`
without the ability to bind would be in a future `GHC20xx`, but we don't
think that `-XPatternSignature` with the ability to bind ought to. (and I
was musing that the ability to bind would be replaced by
`-XTypeAbstractions`).

On Fri, 26 Jan 2024 at 16:43, Richard Eisenberg <reisenberg at janestreet.com>
wrote:

> I'm not sure I understand Arnaud's question here: this proposal removes
> the binding capability from -XPatternSignatures. I don't think there's an
> interaction with -XTypeAbstractions.
>
> On Fri, Jan 26, 2024 at 3:04 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Do we envision, maybe, a future with `-XPatternSignature`, in a version
>> that is incapable of binding and `-XTypeAbstractions`? If so, the split
>> sounds like a reasonable move. Otherwise, the benefit of the split sounds
>> rather slim, and it would need to be weighed against the costs and benefits
>> on the implementation.
>>
>> On Thu, 25 Jan 2024 at 07:07, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> As this is guarded behind a language extension and as such should not
>>> impact any existing code. I'm happy to see this change.
>>>
>>> On Thu, 25 Jan 2024 at 04:43, Adam Gundry <adam at well-typed.com> wrote:
>>>
>>>> I'm also happily in favour, for the reason Joachim articulates.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On 24/01/2024 18:24, Joachim Breitner wrote:
>>>> > Hi,
>>>> >
>>>> > Am Mittwoch, dem 24.01.2024 um 17:32 +0000 schrieb Richard Eisenberg:
>>>> >> - Accepting will make at least one person (John) happy. And I don't
>>>> note anyone who would become unhappy. More happy people is more better. So
>>>> I recommend acceptance. :)
>>>> >
>>>> > unless I am mistaken, this proposal will also un-deprecated
>>>> > -XPatternSignatures, and give it the semantics I asked for in #119:
>>>> > allow me to write
>>>> >
>>>> >     foo :: Monad m => m Int
>>>> >     foo = do
>>>> >       list :: String <- return ""
>>>> >       return $ length list
>>>> >
>>>> > without treading into type variable territory, having to turn on
>>>> > ScopedTypeVariables or anything like that. Finally!
>>>> >
>>>> >
>>>> > So it also makes me a bit happy; in favor.
>>>> >
>>>> > Cheers,
>>>> > Joachim
>>>> >
>>>> >
>>>>
>>>> --
>>>> Adam Gundry, Haskell Consultant
>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>
>>>> Registered in England & Wales, OC335890
>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240126/d0c8ccb0/attachment-0001.html>

From marlowsd at gmail.com  Fri Jan 26 16:46:44 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 26 Jan 2024 16:46:44 +0000
Subject: [ghc-steering-committee] Proposal #612: Change semantics of
 -fhpc to not accumulate data over multiple runs, rec: accept
In-Reply-To: <CAKfdd-zTz0Ko8pm+PpW4uH+GoOBxdy2svt2A53yFCmhQzhxXXw@mail.gmail.com>
References: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
 <CAGwnsn=YkEtx3xSPbjvm9bde2hd7kfzwptKnoxqUBhVRuAC3FA@mail.gmail.com>
 <CAKfdd-zTz0Ko8pm+PpW4uH+GoOBxdy2svt2A53yFCmhQzhxXXw@mail.gmail.com>
Message-ID: <CANsrgPJRNyz_u=ehm40aUzVLaUnv6H-t8Qvk_Zm3HfZoGMts7Q@mail.gmail.com>

Moritz - I agree with everything you say about how users will typically
experience the change, but I don't think a deprecation warning resolves the
concern. As you say, people might be using HPC via automated tooling and
will likely not even see the warning, and even if they do see it will
likely ignore it (I don't know about you, but I don't usually want to be
distracted by some different yak that needs shaving while I'm coding).

IMO we either have to break it completely - i.e. make the existing usage
just fail, after a warning cycle - or don't change it at all. We can't
silently change the behaviour even with a deprecation cycle.

Cheers
Simon

On Thu, 25 Jan 2024 at 10:49, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Here's my rationale for a deprecation period.
>
> Someone who uses hpc, might rely on the accumulating behaviour.  They need
> a way to be informed about the upcoming change, otherwise they won't know
> that they need to pass a new flag going forward (and they can
> even start doing that at that point to be defensive). I also hope the
> deprecation note would show up in automated tooling, which can then be
> proactively adjusted.
>
> To me the compiler is _the_ interface to the end user.  Chances that
> someone reads the proposals, GHC changelog are very low. Chances someone
> reads the user guide in detail for each GHC release are low as well,
> only after the fact, if someone broke will someone start trying to figure
> out why something broke. At that point, I think we've lost. They are
> frustrated already that something they knew worked just broke.
>
> So to me the deprecation note is basically the signage towards the end
> user that uses hpc, that they will need to adjust their ghc invocation if
> they rely on the current behaviour, and also a courtesy heads up that the
> behaviour
> they might rely on changes, _and_ how to adjust and get their old
> behaviour (they may need/rely on) back.
>
> To address your two points in detail:
> > Is a deprecation period necessary? Or even useful (how do we signal the
> upcoming change in default, and how do we expect people would act on it)?
> - As the flag currently does not exist, call GHC with hpc without the new
> flag will issue a warning. (e.g. current users will be informed).
> - The warning message will let the user know what to pass to ghc to retain
> the old (current) behaviour, or opt in to the new (future current)
> behaviour, depending on their needs.
>
> If we did neither, the user would at some point just notice an existing
> workflow magically stopped or in this case even worse, the silent
> aggregation of .tix data would stop, and they
> might _assume_ the data was the aggregate but it wasn't. A silent change
> in default behaviour would be rather painful to notice, debug, and rectify
> for users. At least that's my expectation.
> (And I know I personally would be furious if a compiler pulled that on me).
>
> Best,
>  Moritz
>
> On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> The proposed change seems sensible. At least the argument is convincing.
>> I don't use hpc myself, so I don't have an actual design opinion besides
>> that. So I vote (weakly) for the proposed new default.
>>
>> Is a deprecation period necessary? Or even useful (how do we signal the
>> upcoming change in default, and how do we expect people would act on it)?
>>
>> On Thu, 25 Jan 2024 at 07:06, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> Dear Committee members,
>>>
>>> In Proposal #612
>>> <https://github.com/ghc-proposals/ghc-proposals/pull/612>, David Binder
>>> suggests changing the semantics from `-fhpc` to auto-ingest
>>> existing .tix files for accumulation, towards _not_ auto-ingesting them
>>> and instead overwriting
>>> the .tix file with the coverage of the latest run.
>>>
>>> I agree with his assessment that the current behaviour easily leads to
>>> unexpected surprises. He suggests adding a flag --read-tix-file= to control
>>> this behaviour and defaulting that to _no_, with a grace and
>>> deprecation period prior informing the user that the currently accumulating
>>> feature will change in a future GHC release.
>>>
>>> Adding the flag to control this behaviour is fairly uncontroversial I
>>> hope, however I'd like you to. Weight in on the default. Should we change
>>> the default behaviour, or only add the flag?
>>>
>>> I'd recommend changing the default to --read-tix-file=no after a
>>> deprecation period.
>>>
>>> Best,
>>>  Moritz
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240126/96332e7a/attachment.html>

From reisenberg at janestreet.com  Fri Jan 26 19:30:53 2024
From: reisenberg at janestreet.com (Richard Eisenberg)
Date: Fri, 26 Jan 2024 14:30:53 -0500
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds.  Rec: accept
In-Reply-To: <CAGwnsnn=J9z-yTpHC8eSd4tgacx64OErKXuFaWe=Bv9c=+LKyA@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <23fb994ab7c5c9ca63eac19ddcfc40d6055d4ed7.camel@joachim-breitner.de>
 <12323e8d-0b7d-4263-98ff-df88fbd81665@well-typed.com>
 <CAKfdd-zewu2v+TcV1JGJv=+E-S1FZiOTG9wrM9EPGvsrxuDABw@mail.gmail.com>
 <CAGwnsnnR4B1Ns8MzXUn7Xpy1e5f-=uYQ491z1W6V6Wf77jcQpQ@mail.gmail.com>
 <CALkkMoT-vp=PnCE2tzWzfbTY07-tnS2GvBd8MKzCNt_k7d2b5A@mail.gmail.com>
 <CAGwnsnn=J9z-yTpHC8eSd4tgacx64OErKXuFaWe=Bv9c=+LKyA@mail.gmail.com>
Message-ID: <CALkkMoSvJGgM=95VR3EKs_yGa1Uf2J6SZ06BZcuDX-tb_av5oQ@mail.gmail.com>

Well, -XScopedTypeVariables is in GHC2021, and I think we're generally
imagining increasing the size of this subset, not decreasing it. So the
case you're wondering about (where we'd want one but not the other) seems
unlikely to me.

On the other hand, if I generalize your question a bit to think about
whether we'd want one but not the other in some language edition as in
https://github.com/ghc-proposals/ghc-proposals/pull/628, then quite
possibly. But if we go in that direction, the precise arrangement of
language extensions matters not so much, because that view of the world
removes language extensions from the set of things a user should be
worrying about.

Richard

On Fri, Jan 26, 2024 at 11:10 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> What I was asking was whether we imagined that `-XPatternSignatures`
> without the ability to bind would be in a future `GHC20xx`, but we don't
> think that `-XPatternSignature` with the ability to bind ought to. (and I
> was musing that the ability to bind would be replaced by
> `-XTypeAbstractions`).
>
> On Fri, 26 Jan 2024 at 16:43, Richard Eisenberg <reisenberg at janestreet.com>
> wrote:
>
>> I'm not sure I understand Arnaud's question here: this proposal removes
>> the binding capability from -XPatternSignatures. I don't think there's an
>> interaction with -XTypeAbstractions.
>>
>> On Fri, Jan 26, 2024 at 3:04 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> Do we envision, maybe, a future with `-XPatternSignature`, in a version
>>> that is incapable of binding and `-XTypeAbstractions`? If so, the split
>>> sounds like a reasonable move. Otherwise, the benefit of the split sounds
>>> rather slim, and it would need to be weighed against the costs and benefits
>>> on the implementation.
>>>
>>> On Thu, 25 Jan 2024 at 07:07, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>>
>>>> As this is guarded behind a language extension and as such should not
>>>> impact any existing code. I'm happy to see this change.
>>>>
>>>> On Thu, 25 Jan 2024 at 04:43, Adam Gundry <adam at well-typed.com> wrote:
>>>>
>>>>> I'm also happily in favour, for the reason Joachim articulates.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On 24/01/2024 18:24, Joachim Breitner wrote:
>>>>> > Hi,
>>>>> >
>>>>> > Am Mittwoch, dem 24.01.2024 um 17:32 +0000 schrieb Richard Eisenberg:
>>>>> >> - Accepting will make at least one person (John) happy. And I don't
>>>>> note anyone who would become unhappy. More happy people is more better. So
>>>>> I recommend acceptance. :)
>>>>> >
>>>>> > unless I am mistaken, this proposal will also un-deprecated
>>>>> > -XPatternSignatures, and give it the semantics I asked for in #119:
>>>>> > allow me to write
>>>>> >
>>>>> >     foo :: Monad m => m Int
>>>>> >     foo = do
>>>>> >       list :: String <- return ""
>>>>> >       return $ length list
>>>>> >
>>>>> > without treading into type variable territory, having to turn on
>>>>> > ScopedTypeVariables or anything like that. Finally!
>>>>> >
>>>>> >
>>>>> > So it also makes me a bit happy; in favor.
>>>>> >
>>>>> > Cheers,
>>>>> > Joachim
>>>>> >
>>>>> >
>>>>>
>>>>> --
>>>>> Adam Gundry, Haskell Consultant
>>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>>
>>>>> Registered in England & Wales, OC335890
>>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>>>
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240126/486931b9/attachment-0001.html>

From adam at well-typed.com  Fri Jan 26 20:13:50 2024
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 26 Jan 2024 20:13:50 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <CALkkMoSvJGgM=95VR3EKs_yGa1Uf2J6SZ06BZcuDX-tb_av5oQ@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <23fb994ab7c5c9ca63eac19ddcfc40d6055d4ed7.camel@joachim-breitner.de>
 <12323e8d-0b7d-4263-98ff-df88fbd81665@well-typed.com>
 <CAKfdd-zewu2v+TcV1JGJv=+E-S1FZiOTG9wrM9EPGvsrxuDABw@mail.gmail.com>
 <CAGwnsnnR4B1Ns8MzXUn7Xpy1e5f-=uYQ491z1W6V6Wf77jcQpQ@mail.gmail.com>
 <CALkkMoT-vp=PnCE2tzWzfbTY07-tnS2GvBd8MKzCNt_k7d2b5A@mail.gmail.com>
 <CAGwnsnn=J9z-yTpHC8eSd4tgacx64OErKXuFaWe=Bv9c=+LKyA@mail.gmail.com>
 <CALkkMoSvJGgM=95VR3EKs_yGa1Uf2J6SZ06BZcuDX-tb_av5oQ@mail.gmail.com>
Message-ID: <493eed2d-3b29-46bf-bd55-58e97980c901@well-typed.com>

I would argue that we should be willing to remove (mis)features from 
future GHC20xx editions, and that (the PatternSignatureBinds component 
of) ScopedTypeVariables is potentially such a misfeature. Of course that 
could be quite a disruptive change, so for now I'm happy to see this 
proposal accepted so that we have at least the option of a more 
principled language design in the future.

Incidentally, I respectfully disagree with Richard's characterisation of 
this proposal as merely promoting a warning to be an extension. That 
would be true if PatternSignatureBinds/ScopedTypeVariables was a 
conservative extension, but it isn't - enabling the extension can change 
the meaning of existing programs [1].

Adam


[1] https://gist.github.com/adamgundry/5446f390ee84254c43a0425e821dc930


On 26/01/2024 19:30, Richard Eisenberg wrote:
> Well, -XScopedTypeVariables is in GHC2021, and I think we're generally 
> imagining increasing the size of this subset, not decreasing it. So the 
> case you're wondering about (where we'd want one but not the other) 
> seems unlikely to me.
> 
> On the other hand, if I generalize your question a bit to think about 
> whether we'd want one but not the other in some language edition as in 
> https://github.com/ghc-proposals/ghc-proposals/pull/628 
> <https://github.com/ghc-proposals/ghc-proposals/pull/628>, then quite 
> possibly. But if we go in that direction, the precise arrangement of 
> language extensions matters not so much, because that view of the world 
> removes language extensions from the set of things a user should be 
> worrying about.
> 
> Richard
> 
> On Fri, Jan 26, 2024 at 11:10 AM Arnaud Spiwack <arnaud.spiwack at tweag.io 
> <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
>     What I was asking was whether we imagined that `-XPatternSignatures`
>     without the ability to bind would be in a future `GHC20xx`, but we
>     don't think that `-XPatternSignature` with the ability to bind ought
>     to. (and I was musing that the ability to bind would be replaced by
>     `-XTypeAbstractions`).
> 
>     On Fri, 26 Jan 2024 at 16:43, Richard Eisenberg
>     <reisenberg at janestreet.com <mailto:reisenberg at janestreet.com>> wrote:
> 
>         I'm not sure I understand Arnaud's question here: this proposal
>         removes the binding capability from -XPatternSignatures. I don't
>         think there's an interaction with -XTypeAbstractions.
> 
>         On Fri, Jan 26, 2024 at 3:04 AM Arnaud Spiwack
>         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
>             Do we envision, maybe, a future with `-XPatternSignature`,
>             in a version that is incapable of binding and
>             `-XTypeAbstractions`? If so, the split sounds like a
>             reasonable move. Otherwise, the benefit of the split sounds
>             rather slim, and it would need to be weighed against the
>             costs and benefits on the implementation.
> 
>             On Thu, 25 Jan 2024 at 07:07, Moritz Angermann
>             <moritz.angermann at gmail.com
>             <mailto:moritz.angermann at gmail.com>> wrote:
> 
>                 As this is guarded behind a language extension and as
>                 such should not impact any existing code. I'm happy to
>                 see this change.
> 
>                 On Thu, 25 Jan 2024 at 04:43, Adam Gundry
>                 <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> 
>                     I'm also happily in favour, for the reason Joachim
>                     articulates.
> 
>                     Adam
> 
> 
>                     On 24/01/2024 18:24, Joachim Breitner wrote:
>                      > Hi,
>                      >
>                      > Am Mittwoch, dem 24.01.2024 um 17:32 +0000
>                     schrieb Richard Eisenberg:
>                      >> - Accepting will make at least one person (John)
>                     happy. And I don't note anyone who would become
>                     unhappy. More happy people is more better. So I
>                     recommend acceptance. :)
>                      >
>                      > unless I am mistaken, this proposal will also
>                     un-deprecated
>                      > -XPatternSignatures, and give it the semantics I
>                     asked for in #119:
>                      > allow me to write
>                      >
>                      >     foo :: Monad m => m Int
>                      >     foo = do
>                      >       list :: String <- return ""
>                      >       return $ length list
>                      >
>                      > without treading into type variable territory,
>                     having to turn on
>                      > ScopedTypeVariables or anything like that. Finally!
>                      >
>                      >
>                      > So it also makes me a bit happy; in favor.
>                      >
>                      > Cheers,
>                      > Joachim
>                      >
>                      >


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From adam at well-typed.com  Fri Jan 26 21:22:01 2024
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 26 Jan 2024 21:22:01 +0000
Subject: [ghc-steering-committee] Proposal #612: Change semantics of
 -fhpc to not accumulate data over multiple runs, rec: accept
In-Reply-To: <CANsrgPJRNyz_u=ehm40aUzVLaUnv6H-t8Qvk_Zm3HfZoGMts7Q@mail.gmail.com>
References: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
 <CAGwnsn=YkEtx3xSPbjvm9bde2hd7kfzwptKnoxqUBhVRuAC3FA@mail.gmail.com>
 <CAKfdd-zTz0Ko8pm+PpW4uH+GoOBxdy2svt2A53yFCmhQzhxXXw@mail.gmail.com>
 <CANsrgPJRNyz_u=ehm40aUzVLaUnv6H-t8Qvk_Zm3HfZoGMts7Q@mail.gmail.com>
Message-ID: <7730c9c1-1546-4782-a285-5e1eb278378f@well-typed.com>

If we want to "break it completely", we could introduce a third option 
--read-tix-file=error which will throw an error if an existing .tix file 
is present (much as will currently happen sometimes if a stale .tix file 
is there, but with a better error message).

The deprecation process could then start by introducing a warning if 
--read-tix-file is not specified (while --read-tix-file=yes remains the 
default), then make --read-tix-file=error the default for a release or 
two, before finally adopting --read-tix-file=no as the default we 
actually want.

Is all this worth it? I'm not sure. It seems quite a lot of bureaucracy 
and extra work for David and the rest of the GHC team. At some point, 
perhaps we should expect users to read the release notes if they are 
upgrading the compiler and experiencing changes?

Cheers,

Adam


On 26/01/2024 16:46, Simon Marlow wrote:
> Moritz - I agree with everything you say about how users will typically 
> experience the change, but I don't think a deprecation warning resolves 
> the concern. As you say, people might be using HPC via automated tooling 
> and will likely not even see the warning, and even if they do see it 
> will likely ignore it (I don't know about you, but I don't usually want 
> to be distracted by some different yak that needs shaving while I'm coding).
> 
> IMO we either have to break it completely - i.e. make the existing usage 
> just fail, after a warning cycle - or don't change it at all. We can't 
> silently change the behaviour even with a deprecation cycle.
> 
> Cheers
> Simon
> 
> On Thu, 25 Jan 2024 at 10:49, Moritz Angermann 
> <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
> 
>     Here's my rationale for a deprecation period.
> 
>     Someone who uses hpc, might rely on the accumulating behaviour. 
>     They need a way to be informed about the upcoming change, otherwise
>     they won't know that they need to pass a new flag going forward (and
>     they can
>     even start doing that at that point to be defensive). I also hope
>     the deprecation note would show up in automated tooling, which can
>     then be proactively adjusted.
> 
>     To me the compiler is _the_ interface to the end user.  Chances that
>     someone reads the proposals, GHC changelog are very low. Chances
>     someone reads the user guide in detail for each GHC release are low
>     as well,
>     only after the fact, if someone broke will someone start trying to
>     figure out why something broke. At that point, I think we've lost.
>     They are frustrated already that something they knew worked just broke.
> 
>     So to me the deprecation note is basically the signage towards the
>     end user that uses hpc, that they will need to adjust their ghc
>     invocation if they rely on the current behaviour, and also a
>     courtesy heads up that the behaviour
>     they might rely on changes, _and_ how to adjust and get their old
>     behaviour (they may need/rely on) back.
> 
>     To address your two points in detail:
>      > Is a deprecation period necessary? Or even useful (how do we
>     signal the upcoming change in default, and how do we expect people
>     would act on it)?
>     - As the flag currently does not exist, call GHC with hpc without
>     the new flag will issue a warning. (e.g. current users will be
>     informed).
>     - The warning message will let the user know what to pass to ghc to
>     retain the old (current) behaviour, or opt in to the new (future
>     current) behaviour, depending on their needs.
> 
>     If we did neither, the user would at some point just notice an
>     existing workflow magically stopped or in this case even worse, the
>     silent aggregation of .tix data would stop, and they
>     might _assume_ the data was the aggregate but it wasn't. A silent
>     change in default behaviour would be rather painful to notice,
>     debug, and rectify for users. At least that's my expectation.
>     (And I know I personally would be furious if a compiler pulled that
>     on me).
> 
>     Best,
>       Moritz
> 
>     On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack
>     <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
>         The proposed change seems sensible. At least the argument is
>         convincing. I don't use hpc myself, so I don't have an actual
>         design opinion besides that. So I vote (weakly) for the proposed
>         new default.
> 
>         Is a deprecation period necessary? Or even useful (how do we
>         signal the upcoming change in default, and how do we expect
>         people would act on it)?
> 
>         On Thu, 25 Jan 2024 at 07:06, Moritz Angermann
>         <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>>
>         wrote:
> 
>             Dear Committee members,
> 
>             In Proposal #612
>             <https://github.com/ghc-proposals/ghc-proposals/pull/612>,
>             David Binder suggests changing the semantics from `-fhpc` to
>             auto-ingest
>             existing .tix files for accumulation, towards _not_
>             auto-ingesting them and instead overwriting
>             the .tix file with the coverage of the latest run.
> 
>             I agree with his assessment that the current behaviour
>             easily leads to unexpected surprises. He suggests adding a
>             flag --read-tix-file= to control this behaviour and
>             defaulting that to _no_, with a grace and deprecation period
>             prior informing the user that the currently accumulating
>             feature will change in a future GHC release.
> 
>             Adding the flag to control this behaviour is fairly
>             uncontroversial I hope, however I'd like you to. Weight in
>             on the default. Should we change the default behaviour, or
>             only add the flag?
> 
>             I'd recommend changing the default to --read-tix-file=no
>             after a deprecation period.
> 
>             Best,
>               Moritz
>             _______________________________________________


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From eric at seidel.io  Sat Jan 27 19:25:14 2024
From: eric at seidel.io (Eric Seidel)
Date: Sat, 27 Jan 2024 13:25:14 -0600
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <f693ec0b-f975-4b92-b0ed-85440327a54c@app.fastmail.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
 <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>
 <DF93FE3D-7C65-49DF-BFEA-21E125FE1E61@richarde.dev>
 <010f018cca21abfe-d5746d55-8e13-4243-919b-771753649457-000000@us-east-2.amazonses.com>
 <CAJKmMz-W8i2YHt-80xGTpq7+oTbagzi3zi5ykwpJYrhKcZr5nA@mail.gmail.com>
 <010f018ccf599baf-9998898a-61df-4e17-b8ac-3c7a970e8fd2-000000@us-east-2.amazonses.com>
 <CAJKmMz9rE-bVou1XUE+5fEF_Cw8EtrbH+8RhstOZcu5OLPUSWA@mail.gmail.com>
 <010f018ccf623071-9dd56897-7356-4ca2-835f-5a4df09f963e-000000@us-east-2.amazonses.com>
 <CAJKmMz9jXWzeN6THtD1SbE9wH=aFMD4XPJyLrs_=wANioJku6A@mail.gmail.com>
 <010f018ccf6dc808-374c3c04-defd-4ca5-b5fe-13db67d8e556-000000@us-east-2.amazonses.com>
 <CAJKmMz_GbawR14jEgc5YoMXuNH_FbA5p5ps5ppQwnPAacQ70+A@mail.gmail.com>
 <afdb3f88-cb9f-485a-9645-625d9e4107af@well-typed.com>
 <CAGwnsnn=v5dv3pjbFN2UMeOxOU6KHW789jsDJ8qhe=on=crRAA@mail.gmail.com>
 <f693ec0b-f975-4b92-b0ed-85440327a54c@app.fastmail.com>
Message-ID: <968f8c0b-2be0-4cec-ae24-98438235a5b6@app.fastmail.com>

Ok, I declare this proposal accepted and have merged the GitHub PR.

On Sun, Jan 21, 2024, at 12:28, Eric Seidel wrote:
> SimonM, Vlad,
>
> The rest of the committee has expressed support for this proposal 
> either on the ML or on SimonPJ's Google Sheet[1].
>
> I think that is sufficient consensus to accept, but would prefer to get 
> the full committee on record. 
>
> Please take a few minutes to read the proposal and record your vote. 
> Barring any explicit dissent, I will mark the proposal accepted next 
> weekend.
>
> Eric
>
> [1]: 
> https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing
>
> On Mon, Jan 15, 2024, at 02:21, Arnaud Spiwack wrote:
>> On Sat, 13 Jan 2024 at 21:42, Adam Gundry <adam at well-typed.com> wrote:
>>> On the meta point, I agree with Simon's position here: we should avoid 
>>> giving unconditional acceptance to underspecified proposals, only to 
>>> potentially discover problems later. But where a proposal is not 
>>> precisely specified, it would be preferable to accept in principle (so 
>>> the author is not left wondering whether the idea has a chance) and then 
>>> ask and support the author to finish the spec before merging the PR.
>>
>> I agree too. I was thinking about it over the weekend: we kind of need 
>> a status to say “we pretty much know we're going to accept it, so go 
>> ahead and do the implementation, but we're still working the details 
>> out together” (I was thinking in particular of the choice of string 
>> delimiters from this proposal: it makes no material difference to the 
>> implementation what we eventually settle on. So if there are questions, 
>> we should avoid holding the implementation effort back just because 
>> we're having a discussion about what we think it best).
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From eric at seidel.io  Sat Jan 27 19:43:49 2024
From: eric at seidel.io (Eric Seidel)
Date: Sat, 27 Jan 2024 13:43:49 -0600
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
Message-ID: <0c221fdc-9f28-40d0-863c-fba9dd252da5@app.fastmail.com>

The motivation for this change does not make sense to me. ScopedTypeVariables
is used everywhere and is even part of GHC2021. The goal of this change appears
to be to extract out a controversial piece of PatternSignatures such that it
could be later removed entirely, but without addressing the issue of
ScopedTypeVariables.

That's going about it the wrong way IMO. If we want to remove the behavior
this proposal calls PatternSignatureBinds, the Committee should first adopt
a resolution that we will remove (or alter the meaning of) ScopedTypeVariables
in the next GHC20xx. If we get agreement on that, then this proposal could make
sense as a step towards the broader goal.

Outside of that broader agreement though, this feels more like a fork-inducing
proposal and I would vote against.

On Wed, Jan 24, 2024, at 11:32, Richard Eisenberg wrote:
> John Ericson has submitted proposal #608 
> <https://github.com/ghc-proposals/ghc-proposals/pull/608> about adding 
> -XPatternSignatureBinds. The proposal is an amendment and is thus a 
> little harder to consume. I recommend reading the summary here.
>
> Proposed change:
>
> The proposed -XPatternSignatureBinds takes a piece out from 
> -XPatternSignatures: with only -XPatternSignatures and not 
> -XPatternSignatureBinds, a pattern signature  can mention in-scope type 
> variables but can never bind fresh ones. With -XPatternSignatureBinds, 
> an appearance of an out-of-scope type variable in a pattern signature 
> will cause the variable to be bound to the type it unifies with.
>
> -XScopedTypeVariables will imply -XPatternSignatures 
> -XPatternSignatureBinds (and a few more), so the behavior of 
> -XScopedTypeVariables is completely unchanged. Note that 
> -XPatternSignatures is currently deprecated (and has been so for a long 
> time), so a change in behavior there is not so bad.
>
> Motivation for the change:
>
> - It is awkward to have a rule in a language where scoping behavior 
> depends on what else is in scope. This can confound e.g. tools meant to 
> find the bindings sites of a variable occurrence.
> - The implicit binding we have today plays poorly with the plan to 
> allow users to pretend GHC has a unified namespace. That is, suppose x 
> is in scope as a term variable, and then we have f (... :: ... x ...) = 
> ... . Should that x be bound implicitly there or not? It's pretty 
> unclear. By separating out -XPatternSignatureBinds from 
> -XPatternSignatures, users of the latter are insulated from worrying 
> about this potential future change.
>
> My opinion:
>
> - John has argued that this will make future namespace changes easier. 
> I disagree with this assessment, because -XScopedTypeVariables is 
> utterly pervasive. So the problem that this change is supposed to solve 
> becomes only a tiny bit smaller, benefiting only those users who 
> carefully enable -XPatternSignatures but not, say, 
> -XScopedTypeVariables.
> - But in the end, I don't care all that much. I've come to the opinion 
> that we shouldn't worry about the distinction between warnings and 
> extensions. The net effect of this proposal is to promote a warning 
> into an extension (because we previously had 
> -Wpattern-signature-binds). So if we shouldn't worry about this 
> distinction, then this proposal is a no-op on the aspects of the 
> language we should care about, and thus accepting and rejecting have 
> the same effect. (This little analysis only makes sense because the 
> features are so new -- there's no broad re-education to do or 
> back-compat issues.)
> - Accepting will make at least one person (John) happy. And I don't 
> note anyone who would become unhappy. More happy people is more better. 
> So I recommend acceptance. :)
>
> Please let us know your thoughts!
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From eric at seidel.io  Sat Jan 27 19:51:57 2024
From: eric at seidel.io (Eric Seidel)
Date: Sat, 27 Jan 2024 13:51:57 -0600
Subject: [ghc-steering-committee] Proposal #612: Change semantics of
 -fhpc to not accumulate data over multiple runs, rec: accept
In-Reply-To: <7730c9c1-1546-4782-a285-5e1eb278378f@well-typed.com>
References: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
 <CAGwnsn=YkEtx3xSPbjvm9bde2hd7kfzwptKnoxqUBhVRuAC3FA@mail.gmail.com>
 <CAKfdd-zTz0Ko8pm+PpW4uH+GoOBxdy2svt2A53yFCmhQzhxXXw@mail.gmail.com>
 <CANsrgPJRNyz_u=ehm40aUzVLaUnv6H-t8Qvk_Zm3HfZoGMts7Q@mail.gmail.com>
 <7730c9c1-1546-4782-a285-5e1eb278378f@well-typed.com>
Message-ID: <8a545798-4361-4df2-a173-9318cae791ed@app.fastmail.com>

The change itself makes sense to me, non-accumulating semantics seem like
a much better default.

I also think this is a case where users should be expected to read the
Release Notes. Just highlight the change of default behavior at the top
and move on.

On Fri, Jan 26, 2024, at 15:22, Adam Gundry wrote:
> If we want to "break it completely", we could introduce a third option 
> --read-tix-file=error which will throw an error if an existing .tix file 
> is present (much as will currently happen sometimes if a stale .tix file 
> is there, but with a better error message).
>
> The deprecation process could then start by introducing a warning if 
> --read-tix-file is not specified (while --read-tix-file=yes remains the 
> default), then make --read-tix-file=error the default for a release or 
> two, before finally adopting --read-tix-file=no as the default we 
> actually want.
>
> Is all this worth it? I'm not sure. It seems quite a lot of bureaucracy 
> and extra work for David and the rest of the GHC team. At some point, 
> perhaps we should expect users to read the release notes if they are 
> upgrading the compiler and experiencing changes?
>
> Cheers,
>
> Adam
>
>
> On 26/01/2024 16:46, Simon Marlow wrote:
>> Moritz - I agree with everything you say about how users will typically 
>> experience the change, but I don't think a deprecation warning resolves 
>> the concern. As you say, people might be using HPC via automated tooling 
>> and will likely not even see the warning, and even if they do see it 
>> will likely ignore it (I don't know about you, but I don't usually want 
>> to be distracted by some different yak that needs shaving while I'm coding).
>> 
>> IMO we either have to break it completely - i.e. make the existing usage 
>> just fail, after a warning cycle - or don't change it at all. We can't 
>> silently change the behaviour even with a deprecation cycle.
>> 
>> Cheers
>> Simon
>> 
>> On Thu, 25 Jan 2024 at 10:49, Moritz Angermann 
>> <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>> 
>>     Here's my rationale for a deprecation period.
>> 
>>     Someone who uses hpc, might rely on the accumulating behaviour. 
>>     They need a way to be informed about the upcoming change, otherwise
>>     they won't know that they need to pass a new flag going forward (and
>>     they can
>>     even start doing that at that point to be defensive). I also hope
>>     the deprecation note would show up in automated tooling, which can
>>     then be proactively adjusted.
>> 
>>     To me the compiler is _the_ interface to the end user.  Chances that
>>     someone reads the proposals, GHC changelog are very low. Chances
>>     someone reads the user guide in detail for each GHC release are low
>>     as well,
>>     only after the fact, if someone broke will someone start trying to
>>     figure out why something broke. At that point, I think we've lost.
>>     They are frustrated already that something they knew worked just broke.
>> 
>>     So to me the deprecation note is basically the signage towards the
>>     end user that uses hpc, that they will need to adjust their ghc
>>     invocation if they rely on the current behaviour, and also a
>>     courtesy heads up that the behaviour
>>     they might rely on changes, _and_ how to adjust and get their old
>>     behaviour (they may need/rely on) back.
>> 
>>     To address your two points in detail:
>>      > Is a deprecation period necessary? Or even useful (how do we
>>     signal the upcoming change in default, and how do we expect people
>>     would act on it)?
>>     - As the flag currently does not exist, call GHC with hpc without
>>     the new flag will issue a warning. (e.g. current users will be
>>     informed).
>>     - The warning message will let the user know what to pass to ghc to
>>     retain the old (current) behaviour, or opt in to the new (future
>>     current) behaviour, depending on their needs.
>> 
>>     If we did neither, the user would at some point just notice an
>>     existing workflow magically stopped or in this case even worse, the
>>     silent aggregation of .tix data would stop, and they
>>     might _assume_ the data was the aggregate but it wasn't. A silent
>>     change in default behaviour would be rather painful to notice,
>>     debug, and rectify for users. At least that's my expectation.
>>     (And I know I personally would be furious if a compiler pulled that
>>     on me).
>> 
>>     Best,
>>       Moritz
>> 
>>     On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack
>>     <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>> 
>>         The proposed change seems sensible. At least the argument is
>>         convincing. I don't use hpc myself, so I don't have an actual
>>         design opinion besides that. So I vote (weakly) for the proposed
>>         new default.
>> 
>>         Is a deprecation period necessary? Or even useful (how do we
>>         signal the upcoming change in default, and how do we expect
>>         people would act on it)?
>> 
>>         On Thu, 25 Jan 2024 at 07:06, Moritz Angermann
>>         <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>>
>>         wrote:
>> 
>>             Dear Committee members,
>> 
>>             In Proposal #612
>>             <https://github.com/ghc-proposals/ghc-proposals/pull/612>,
>>             David Binder suggests changing the semantics from `-fhpc` to
>>             auto-ingest
>>             existing .tix files for accumulation, towards _not_
>>             auto-ingesting them and instead overwriting
>>             the .tix file with the coverage of the latest run.
>> 
>>             I agree with his assessment that the current behaviour
>>             easily leads to unexpected surprises. He suggests adding a
>>             flag --read-tix-file= to control this behaviour and
>>             defaulting that to _no_, with a grace and deprecation period
>>             prior informing the user that the currently accumulating
>>             feature will change in a future GHC release.
>> 
>>             Adding the flag to control this behaviour is fairly
>>             uncontroversial I hope, however I'd like you to. Weight in
>>             on the default. Should we change the default behaviour, or
>>             only add the flag?
>> 
>>             I'd recommend changing the default to --read-tix-file=no
>>             after a deprecation period.
>> 
>>             Best,
>>               Moritz
>>             _______________________________________________
>
>
> -- 
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From adam at well-typed.com  Sat Jan 27 20:15:09 2024
From: adam at well-typed.com (Adam Gundry)
Date: Sat, 27 Jan 2024 20:15:09 +0000
Subject: [ghc-steering-committee] Please review #631: Set program exit code
 by main return type, Shepherd: Arnaud
Message-ID: <d89aa1d0-59ff-4a1c-b460-8bd2803fae25@well-typed.com>

Dear Committee,

Shea Levy proposes that the value returned by `main` should determine 
the exit code of the program:

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

https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst

I'd like to nominate Arnaud as the shepherd.

Please guide us to a conclusion as outlined in
https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

From simon.peytonjones at gmail.com  Sat Jan 27 22:56:06 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sat, 27 Jan 2024 22:56:06 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <0c221fdc-9f28-40d0-863c-fba9dd252da5@app.fastmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <0c221fdc-9f28-40d0-863c-fba9dd252da5@app.fastmail.com>
Message-ID: <CAJKmMz9eTPXLyRCZafMC19k-gu8bJjD7kMsqTPaSkGB+SLc18Q@mail.gmail.com>

To me this looks uncontroversial.

   - We have a currently-deprecated extension -XPatternSignatures
   - This proposal rehabilitates it (with a narrower scope than before) and
   adds a new one -XPatternSignatureBinds
   - If you don't use these extensions they won't harm you
   - The behaviour of -XScopedTypeVariables is unchanged

It's a fairly tiny thing, easy to implement, easy to document.  I don't
care very much, but I'm content to approve it.

My only regret is that we don't have a "warning form" for language
extensions (see https://github.com/ghc-proposals/ghc-proposals/pull/620) .
I'd like to say -WPatternSignatureBinds, meaning to allow
pattern-signatures to bind, but warn on every such occasion.  Lacking such
a "warning form" we have to *also* have `-Wpattern-signature-binds`.

Eric, I'm not sure what specifically you are objecting to.  Are you making
a philosophical point, or is there active harm here?

Simon

On Sat, 27 Jan 2024 at 19:44, Eric Seidel <eric at seidel.io> wrote:

> The motivation for this change does not make sense to me.
> ScopedTypeVariables
> is used everywhere and is even part of GHC2021. The goal of this change
> appears
> to be to extract out a controversial piece of PatternSignatures such that
> it
> could be later removed entirely, but without addressing the issue of
> ScopedTypeVariables.
>
> That's going about it the wrong way IMO. If we want to remove the behavior
> this proposal calls PatternSignatureBinds, the Committee should first adopt
> a resolution that we will remove (or alter the meaning of)
> ScopedTypeVariables
> in the next GHC20xx. If we get agreement on that, then this proposal could
> make
> sense as a step towards the broader goal.
>
> Outside of that broader agreement though, this feels more like a
> fork-inducing
> proposal and I would vote against.
>
> On Wed, Jan 24, 2024, at 11:32, Richard Eisenberg wrote:
> > John Ericson has submitted proposal #608
> > <https://github.com/ghc-proposals/ghc-proposals/pull/608> about adding
> > -XPatternSignatureBinds. The proposal is an amendment and is thus a
> > little harder to consume. I recommend reading the summary here.
> >
> > Proposed change:
> >
> > The proposed -XPatternSignatureBinds takes a piece out from
> > -XPatternSignatures: with only -XPatternSignatures and not
> > -XPatternSignatureBinds, a pattern signature  can mention in-scope type
> > variables but can never bind fresh ones. With -XPatternSignatureBinds,
> > an appearance of an out-of-scope type variable in a pattern signature
> > will cause the variable to be bound to the type it unifies with.
> >
> > -XScopedTypeVariables will imply -XPatternSignatures
> > -XPatternSignatureBinds (and a few more), so the behavior of
> > -XScopedTypeVariables is completely unchanged. Note that
> > -XPatternSignatures is currently deprecated (and has been so for a long
> > time), so a change in behavior there is not so bad.
> >
> > Motivation for the change:
> >
> > - It is awkward to have a rule in a language where scoping behavior
> > depends on what else is in scope. This can confound e.g. tools meant to
> > find the bindings sites of a variable occurrence.
> > - The implicit binding we have today plays poorly with the plan to
> > allow users to pretend GHC has a unified namespace. That is, suppose x
> > is in scope as a term variable, and then we have f (... :: ... x ...) =
> > ... . Should that x be bound implicitly there or not? It's pretty
> > unclear. By separating out -XPatternSignatureBinds from
> > -XPatternSignatures, users of the latter are insulated from worrying
> > about this potential future change.
> >
> > My opinion:
> >
> > - John has argued that this will make future namespace changes easier.
> > I disagree with this assessment, because -XScopedTypeVariables is
> > utterly pervasive. So the problem that this change is supposed to solve
> > becomes only a tiny bit smaller, benefiting only those users who
> > carefully enable -XPatternSignatures but not, say,
> > -XScopedTypeVariables.
> > - But in the end, I don't care all that much. I've come to the opinion
> > that we shouldn't worry about the distinction between warnings and
> > extensions. The net effect of this proposal is to promote a warning
> > into an extension (because we previously had
> > -Wpattern-signature-binds). So if we shouldn't worry about this
> > distinction, then this proposal is a no-op on the aspects of the
> > language we should care about, and thus accepting and rejecting have
> > the same effect. (This little analysis only makes sense because the
> > features are so new -- there's no broad re-education to do or
> > back-compat issues.)
> > - Accepting will make at least one person (John) happy. And I don't
> > note anyone who would become unhappy. More happy people is more better.
> > So I recommend acceptance. :)
> >
> > Please let us know your thoughts!
> > Richard
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240127/33f7f549/attachment.html>

From eric at seidel.io  Sun Jan 28 00:12:15 2024
From: eric at seidel.io (Eric Seidel)
Date: Sat, 27 Jan 2024 18:12:15 -0600
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <CAJKmMz9eTPXLyRCZafMC19k-gu8bJjD7kMsqTPaSkGB+SLc18Q@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <0c221fdc-9f28-40d0-863c-fba9dd252da5@app.fastmail.com>
 <CAJKmMz9eTPXLyRCZafMC19k-gu8bJjD7kMsqTPaSkGB+SLc18Q@mail.gmail.com>
Message-ID: <8ca203b8-650f-474d-804d-0e6759c746cb@app.fastmail.com>

I think it's mostly a philosophical point. We have GHC2021 which is the
current "blessed" version of the language. It includes ScopedTypeVariables,
which if I understand correctly is a superset of PatternSigs. We also want
to move in the direction of having *fewer* interacting extensions. In my
mind that is one of the main motivations for introducing the GHC20xx
standards. When I review a proposal for a new extension, one of the
questions I ask myself is "would I eventually support including this in
a GHC20xx standard?" If the answer is no (and if the extension is not one
of the advanced or niche things like CPP), then I'm much less likely to
support it.

So what is the purpose of refactoring extensions that are implied by
ScopedTypeVariables? It seems like needless churn if ScopedTypeVariables
is here to stay. On the other hand, if we mean to change ScopedTypeVariables
we should be explicit about that. 

On Sat, Jan 27, 2024, at 16:56, Simon Peyton Jones wrote:
> To me this looks uncontroversial.  
>  • We have a currently-deprecated extension -XPatternSignatures
>  • This proposal rehabilitates it (with a narrower scope than before) 
> and adds a new one -XPatternSignatureBinds
>  • If you don't use these extensions they won't harm you
>  • The behaviour of -XScopedTypeVariables is unchanged
> It's a fairly tiny thing, easy to implement, easy to document.  I don't 
> care very much, but I'm content to approve it.
>
> My only regret is that we don't have a "warning form" for language 
> extensions (see 
> https://github.com/ghc-proposals/ghc-proposals/pull/620) . I'd like to 
> say -WPatternSignatureBinds, meaning to allow pattern-signatures to 
> bind, but warn on every such occasion.  Lacking such a "warning form" 
> we have to *also* have `-Wpattern-signature-binds`.
>
> Eric, I'm not sure what specifically you are objecting to.  Are you 
> making a philosophical point, or is there active harm here?
>
> Simon
>
> On Sat, 27 Jan 2024 at 19:44, Eric Seidel <eric at seidel.io> wrote:
>> The motivation for this change does not make sense to me. ScopedTypeVariables
>> is used everywhere and is even part of GHC2021. The goal of this change appears
>> to be to extract out a controversial piece of PatternSignatures such that it
>> could be later removed entirely, but without addressing the issue of
>> ScopedTypeVariables.
>> 
>> That's going about it the wrong way IMO. If we want to remove the behavior
>> this proposal calls PatternSignatureBinds, the Committee should first adopt
>> a resolution that we will remove (or alter the meaning of) ScopedTypeVariables
>> in the next GHC20xx. If we get agreement on that, then this proposal could make
>> sense as a step towards the broader goal.
>> 
>> Outside of that broader agreement though, this feels more like a fork-inducing
>> proposal and I would vote against.
>> 
>> On Wed, Jan 24, 2024, at 11:32, Richard Eisenberg wrote:
>> > John Ericson has submitted proposal #608 
>> > <https://github.com/ghc-proposals/ghc-proposals/pull/608> about adding 
>> > -XPatternSignatureBinds. The proposal is an amendment and is thus a 
>> > little harder to consume. I recommend reading the summary here.
>> >
>> > Proposed change:
>> >
>> > The proposed -XPatternSignatureBinds takes a piece out from 
>> > -XPatternSignatures: with only -XPatternSignatures and not 
>> > -XPatternSignatureBinds, a pattern signature  can mention in-scope type 
>> > variables but can never bind fresh ones. With -XPatternSignatureBinds, 
>> > an appearance of an out-of-scope type variable in a pattern signature 
>> > will cause the variable to be bound to the type it unifies with.
>> >
>> > -XScopedTypeVariables will imply -XPatternSignatures 
>> > -XPatternSignatureBinds (and a few more), so the behavior of 
>> > -XScopedTypeVariables is completely unchanged. Note that 
>> > -XPatternSignatures is currently deprecated (and has been so for a long 
>> > time), so a change in behavior there is not so bad.
>> >
>> > Motivation for the change:
>> >
>> > - It is awkward to have a rule in a language where scoping behavior 
>> > depends on what else is in scope. This can confound e.g. tools meant to 
>> > find the bindings sites of a variable occurrence.
>> > - The implicit binding we have today plays poorly with the plan to 
>> > allow users to pretend GHC has a unified namespace. That is, suppose x 
>> > is in scope as a term variable, and then we have f (... :: ... x ...) = 
>> > ... . Should that x be bound implicitly there or not? It's pretty 
>> > unclear. By separating out -XPatternSignatureBinds from 
>> > -XPatternSignatures, users of the latter are insulated from worrying 
>> > about this potential future change.
>> >
>> > My opinion:
>> >
>> > - John has argued that this will make future namespace changes easier. 
>> > I disagree with this assessment, because -XScopedTypeVariables is 
>> > utterly pervasive. So the problem that this change is supposed to solve 
>> > becomes only a tiny bit smaller, benefiting only those users who 
>> > carefully enable -XPatternSignatures but not, say, 
>> > -XScopedTypeVariables.
>> > - But in the end, I don't care all that much. I've come to the opinion 
>> > that we shouldn't worry about the distinction between warnings and 
>> > extensions. The net effect of this proposal is to promote a warning 
>> > into an extension (because we previously had 
>> > -Wpattern-signature-binds). So if we shouldn't worry about this 
>> > distinction, then this proposal is a no-op on the aspects of the 
>> > language we should care about, and thus accepting and rejecting have 
>> > the same effect. (This little analysis only makes sense because the 
>> > features are so new -- there's no broad re-education to do or 
>> > back-compat issues.)
>> > - Accepting will make at least one person (John) happy. And I don't 
>> > note anyone who would become unhappy. More happy people is more better. 
>> > So I recommend acceptance. :)
>> >
>> > Please let us know your thoughts!
>> > Richard
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org
>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From simon.peytonjones at gmail.com  Sun Jan 28 18:22:18 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sun, 28 Jan 2024 18:22:18 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <8ca203b8-650f-474d-804d-0e6759c746cb@app.fastmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <0c221fdc-9f28-40d0-863c-fba9dd252da5@app.fastmail.com>
 <CAJKmMz9eTPXLyRCZafMC19k-gu8bJjD7kMsqTPaSkGB+SLc18Q@mail.gmail.com>
 <8ca203b8-650f-474d-804d-0e6759c746cb@app.fastmail.com>
Message-ID: <CAJKmMz_UPvpuEub5Q=3j7CbCyr1fMbwGkOBCF+F3vq9eahaRxQ@mail.gmail.com>

When I review a proposal for a new extension, one of the
questions I ask myself is "would I eventually support including this in
a GHC20xx standard?" If the answer is no (and if the extension is not one
of the advanced or niche things like CPP), then I'm much less likely to
support it.


Aha.  Now I understand your point thanks.

In the glorious future, what do we want?

   - Plan A.   "A pattern signature brings into scope any variables that
   aren't already in scope".  It's a bit of a tricky rule. If we see `f (Just
   x) = rhs` we know that it brings `x` into scope regardless.  Simple.  No so
   with pattern-signatures!

   - Plan B.   Pattern signatures never bring anything into scope.  To do
   that, use @type patterns.  For example, instead of
       f (Just (x::a)) = rhs
   say
       f (Just @a x) = rhs
   Now it's clear that `a` is being brought into scope.

I lean towards Plan B, but you raise a good point.  I'd love to know what
our consensus is.   RSVP steering committee members.

Simon

On Sun, 28 Jan 2024 at 00:12, Eric Seidel <eric at seidel.io> wrote:

> I think it's mostly a philosophical point. We have GHC2021 which is the
> current "blessed" version of the language. It includes ScopedTypeVariables,
> which if I understand correctly is a superset of PatternSigs. We also want
> to move in the direction of having *fewer* interacting extensions. In my
> mind that is one of the main motivations for introducing the GHC20xx
> standards. When I review a proposal for a new extension, one of the
> questions I ask myself is "would I eventually support including this in
> a GHC20xx standard?" If the answer is no (and if the extension is not one
> of the advanced or niche things like CPP), then I'm much less likely to
> support it.
>
> So what is the purpose of refactoring extensions that are implied by
> ScopedTypeVariables? It seems like needless churn if ScopedTypeVariables
> is here to stay. On the other hand, if we mean to change
> ScopedTypeVariables
> we should be explicit about that.
>
> On Sat, Jan 27, 2024, at 16:56, Simon Peyton Jones wrote:
> > To me this looks uncontroversial.
> >  • We have a currently-deprecated extension -XPatternSignatures
> >  • This proposal rehabilitates it (with a narrower scope than before)
> > and adds a new one -XPatternSignatureBinds
> >  • If you don't use these extensions they won't harm you
> >  • The behaviour of -XScopedTypeVariables is unchanged
> > It's a fairly tiny thing, easy to implement, easy to document.  I don't
> > care very much, but I'm content to approve it.
> >
> > My only regret is that we don't have a "warning form" for language
> > extensions (see
> > https://github.com/ghc-proposals/ghc-proposals/pull/620) . I'd like to
> > say -WPatternSignatureBinds, meaning to allow pattern-signatures to
> > bind, but warn on every such occasion.  Lacking such a "warning form"
> > we have to *also* have `-Wpattern-signature-binds`.
> >
> > Eric, I'm not sure what specifically you are objecting to.  Are you
> > making a philosophical point, or is there active harm here?
> >
> > Simon
> >
> > On Sat, 27 Jan 2024 at 19:44, Eric Seidel <eric at seidel.io> wrote:
> >> The motivation for this change does not make sense to me.
> ScopedTypeVariables
> >> is used everywhere and is even part of GHC2021. The goal of this change
> appears
> >> to be to extract out a controversial piece of PatternSignatures such
> that it
> >> could be later removed entirely, but without addressing the issue of
> >> ScopedTypeVariables.
> >>
> >> That's going about it the wrong way IMO. If we want to remove the
> behavior
> >> this proposal calls PatternSignatureBinds, the Committee should first
> adopt
> >> a resolution that we will remove (or alter the meaning of)
> ScopedTypeVariables
> >> in the next GHC20xx. If we get agreement on that, then this proposal
> could make
> >> sense as a step towards the broader goal.
> >>
> >> Outside of that broader agreement though, this feels more like a
> fork-inducing
> >> proposal and I would vote against.
> >>
> >> On Wed, Jan 24, 2024, at 11:32, Richard Eisenberg wrote:
> >> > John Ericson has submitted proposal #608
> >> > <https://github.com/ghc-proposals/ghc-proposals/pull/608> about
> adding
> >> > -XPatternSignatureBinds. The proposal is an amendment and is thus a
> >> > little harder to consume. I recommend reading the summary here.
> >> >
> >> > Proposed change:
> >> >
> >> > The proposed -XPatternSignatureBinds takes a piece out from
> >> > -XPatternSignatures: with only -XPatternSignatures and not
> >> > -XPatternSignatureBinds, a pattern signature  can mention in-scope
> type
> >> > variables but can never bind fresh ones. With
> -XPatternSignatureBinds,
> >> > an appearance of an out-of-scope type variable in a pattern signature
> >> > will cause the variable to be bound to the type it unifies with.
> >> >
> >> > -XScopedTypeVariables will imply -XPatternSignatures
> >> > -XPatternSignatureBinds (and a few more), so the behavior of
> >> > -XScopedTypeVariables is completely unchanged. Note that
> >> > -XPatternSignatures is currently deprecated (and has been so for a
> long
> >> > time), so a change in behavior there is not so bad.
> >> >
> >> > Motivation for the change:
> >> >
> >> > - It is awkward to have a rule in a language where scoping behavior
> >> > depends on what else is in scope. This can confound e.g. tools meant
> to
> >> > find the bindings sites of a variable occurrence.
> >> > - The implicit binding we have today plays poorly with the plan to
> >> > allow users to pretend GHC has a unified namespace. That is, suppose
> x
> >> > is in scope as a term variable, and then we have f (... :: ... x ...)
> =
> >> > ... . Should that x be bound implicitly there or not? It's pretty
> >> > unclear. By separating out -XPatternSignatureBinds from
> >> > -XPatternSignatures, users of the latter are insulated from worrying
> >> > about this potential future change.
> >> >
> >> > My opinion:
> >> >
> >> > - John has argued that this will make future namespace changes
> easier.
> >> > I disagree with this assessment, because -XScopedTypeVariables is
> >> > utterly pervasive. So the problem that this change is supposed to
> solve
> >> > becomes only a tiny bit smaller, benefiting only those users who
> >> > carefully enable -XPatternSignatures but not, say,
> >> > -XScopedTypeVariables.
> >> > - But in the end, I don't care all that much. I've come to the
> opinion
> >> > that we shouldn't worry about the distinction between warnings and
> >> > extensions. The net effect of this proposal is to promote a warning
> >> > into an extension (because we previously had
> >> > -Wpattern-signature-binds). So if we shouldn't worry about this
> >> > distinction, then this proposal is a no-op on the aspects of the
> >> > language we should care about, and thus accepting and rejecting have
> >> > the same effect. (This little analysis only makes sense because the
> >> > features are so new -- there's no broad re-education to do or
> >> > back-compat issues.)
> >> > - Accepting will make at least one person (John) happy. And I don't
> >> > note anyone who would become unhappy. More happy people is more
> better.
> >> > So I recommend acceptance. :)
> >> >
> >> > Please let us know your thoughts!
> >> > Richard
> >> > _______________________________________________
> >> > ghc-steering-committee mailing list
> >> > ghc-steering-committee at haskell.org
> >> >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240128/402bca4e/attachment.html>

From eric at seidel.io  Mon Jan 29 00:50:00 2024
From: eric at seidel.io (Eric Seidel)
Date: Sun, 28 Jan 2024 18:50:00 -0600
Subject: [ghc-steering-committee] Proposal #608,
	-XPatternSignatureBinds. Rec: accept
In-Reply-To: <CAJKmMz_UPvpuEub5Q=3j7CbCyr1fMbwGkOBCF+F3vq9eahaRxQ@mail.gmail.com>
References: <CAJKmMz_UPvpuEub5Q=3j7CbCyr1fMbwGkOBCF+F3vq9eahaRxQ@mail.gmail.com>
Message-ID: <A36D6E9A-B7DC-49A2-9D8C-D69EA4E13368@seidel.io>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240128/e7c75d47/attachment-0001.html>

From adam at well-typed.com  Mon Jan 29 08:05:19 2024
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 29 Jan 2024 08:05:19 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <A36D6E9A-B7DC-49A2-9D8C-D69EA4E13368@seidel.io>
References: <CAJKmMz_UPvpuEub5Q=3j7CbCyr1fMbwGkOBCF+F3vq9eahaRxQ@mail.gmail.com>
 <A36D6E9A-B7DC-49A2-9D8C-D69EA4E13368@seidel.io>
Message-ID: <2146c6d1-1892-4d6f-8ebf-3058baaa0cad@well-typed.com>

It's clear that a lot of existing code expects A. Deprecating 
PatternSignatureBinds/ScopedTypeVariables is surely off the table for 
the foreseeable future, because it would be much too disruptive. But it 
would be a shame if GHC didn't make it *possible* to do B, which is all 
this proposal entails.

I think it's too early to say whether removing 
PatternSignatureBinds/ScopedTypeVariables from a future GHC20xx will be 
a good idea at some point. It's conceivable, because as we've discussed 
before, it is possible to remove features from future GHC20xx editions 
without breaking existing code and while still supporting the features 
for backwards compatibility (perhaps indefinitely). And that should be 
enough to justify accepting this proposal IMHO.

Adam


On 29/01/2024 00:50, Eric Seidel wrote:
> Yep that’s the question.
> 
> If we were starting from scratch I would agree that B is better. But I 
> worry that there may be a lot of code out there that expects A.
> 
> So then this becomes a question of tradeoffs, is the simplification 
> benefit of this change sufficient to justify the migration cost we may 
> be imposing on the community?
> 
> It seems unlikely to me.
> 
> Sent from my iPhone
> 
>> On Jan 28, 2024, at 12:22, Simon Peyton Jones 
>> <simon.peytonjones at gmail.com> wrote:
>>
>> 
>>
>>     When I review a proposal for a new extension, one of the
>>     questions I ask myself is "would I eventually support including
>>     this in
>>     a GHC20xx standard?" If the answer is no (and if the extension is
>>     not one
>>     of the advanced or niche things like CPP), then I'm much less
>>     likely to
>>     support it. 
>>
>>
>> Aha.  Now I understand your point thanks.
>>
>> In the glorious future, what do we want?
>>
>>   * Plan A.   "A pattern signature brings into scope any variables
>>     that aren't already in scope".  It's a bit of a tricky rule. If we
>>     see `f (Just x) = rhs` we know that it brings `x` into scope
>>     regardless.  Simple.  No so with pattern-signatures!
>>
>>   * Plan B.   Pattern signatures never bring anything into scope.  To
>>     do that, use @type patterns.  For example, instead of
>>         f (Just (x::a)) = rhs
>>     say
>>         f (Just @a x) = rhs
>>     Now it's clear that `a` is being brought into scope.
>>
>> I lean towards Plan B, but you raise a good point.  I'd love to know 
>> what our consensus is.   RSVP steering committee members.
>>
>> Simon
>>
>> On Sun, 28 Jan 2024 at 00:12, Eric Seidel <eric at seidel.io 
>> <mailto:eric at seidel.io>> wrote:
>>
>>     I think it's mostly a philosophical point. We have GHC2021 which
>>     is the
>>     current "blessed" version of the language. It includes
>>     ScopedTypeVariables,
>>     which if I understand correctly is a superset of PatternSigs. We
>>     also want
>>     to move in the direction of having *fewer* interacting extensions.
>>     In my
>>     mind that is one of the main motivations for introducing the GHC20xx
>>     standards. When I review a proposal for a new extension, one of the
>>     questions I ask myself is "would I eventually support including
>>     this in
>>     a GHC20xx standard?" If the answer is no (and if the extension is
>>     not one
>>     of the advanced or niche things like CPP), then I'm much less
>>     likely to
>>     support it.
>>
>>     So what is the purpose of refactoring extensions that are implied by
>>     ScopedTypeVariables? It seems like needless churn if
>>     ScopedTypeVariables
>>     is here to stay. On the other hand, if we mean to change
>>     ScopedTypeVariables
>>     we should be explicit about that.
>>
>>     On Sat, Jan 27, 2024, at 16:56, Simon Peyton Jones wrote:
>>     > To me this looks uncontroversial.
>>     >  • We have a currently-deprecated extension -XPatternSignatures
>>     >  • This proposal rehabilitates it (with a narrower scope than
>>     before)
>>     > and adds a new one -XPatternSignatureBinds
>>     >  • If you don't use these extensions they won't harm you
>>     >  • The behaviour of -XScopedTypeVariables is unchanged
>>     > It's a fairly tiny thing, easy to implement, easy to document. 
>>     I don't
>>     > care very much, but I'm content to approve it.
>>     >
>>     > My only regret is that we don't have a "warning form" for language
>>     > extensions (see
>>     > https://github.com/ghc-proposals/ghc-proposals/pull/620
>>     <https://github.com/ghc-proposals/ghc-proposals/pull/620>) . I'd
>>     like to
>>     > say -WPatternSignatureBinds, meaning to allow pattern-signatures to
>>     > bind, but warn on every such occasion.  Lacking such a "warning
>>     form"
>>     > we have to *also* have `-Wpattern-signature-binds`.
>>     >
>>     > Eric, I'm not sure what specifically you are objecting to.  Are you
>>     > making a philosophical point, or is there active harm here?
>>     >
>>     > Simon
>>     >
>>     > On Sat, 27 Jan 2024 at 19:44, Eric Seidel <eric at seidel.io
>>     <mailto:eric at seidel.io>> wrote:
>>     >> The motivation for this change does not make sense to me.
>>     ScopedTypeVariables
>>     >> is used everywhere and is even part of GHC2021. The goal of
>>     this change appears
>>     >> to be to extract out a controversial piece of PatternSignatures
>>     such that it
>>     >> could be later removed entirely, but without addressing the
>>     issue of
>>     >> ScopedTypeVariables.
>>     >>
>>     >> That's going about it the wrong way IMO. If we want to remove
>>     the behavior
>>     >> this proposal calls PatternSignatureBinds, the Committee should
>>     first adopt
>>     >> a resolution that we will remove (or alter the meaning of)
>>     ScopedTypeVariables
>>     >> in the next GHC20xx. If we get agreement on that, then this
>>     proposal could make
>>     >> sense as a step towards the broader goal.
>>     >>
>>     >> Outside of that broader agreement though, this feels more like
>>     a fork-inducing
>>     >> proposal and I would vote against.
>>     >>
>>     >> On Wed, Jan 24, 2024, at 11:32, Richard Eisenberg wrote:
>>     >> > John Ericson has submitted proposal #608
>>     >> > <https://github.com/ghc-proposals/ghc-proposals/pull/608
>>     <https://github.com/ghc-proposals/ghc-proposals/pull/608>> about
>>     adding
>>     >> > -XPatternSignatureBinds. The proposal is an amendment and is
>>     thus a
>>     >> > little harder to consume. I recommend reading the summary here.
>>     >> >
>>     >> > Proposed change:
>>     >> >
>>     >> > The proposed -XPatternSignatureBinds takes a piece out from
>>     >> > -XPatternSignatures: with only -XPatternSignatures and not
>>     >> > -XPatternSignatureBinds, a pattern signature  can mention
>>     in-scope type
>>     >> > variables but can never bind fresh ones. With
>>     -XPatternSignatureBinds,
>>     >> > an appearance of an out-of-scope type variable in a pattern
>>     signature
>>     >> > will cause the variable to be bound to the type it unifies with.
>>     >> >
>>     >> > -XScopedTypeVariables will imply -XPatternSignatures
>>     >> > -XPatternSignatureBinds (and a few more), so the behavior of
>>     >> > -XScopedTypeVariables is completely unchanged. Note that
>>     >> > -XPatternSignatures is currently deprecated (and has been so
>>     for a long
>>     >> > time), so a change in behavior there is not so bad.
>>     >> >
>>     >> > Motivation for the change:
>>     >> >
>>     >> > - It is awkward to have a rule in a language where scoping
>>     behavior
>>     >> > depends on what else is in scope. This can confound e.g.
>>     tools meant to
>>     >> > find the bindings sites of a variable occurrence.
>>     >> > - The implicit binding we have today plays poorly with the
>>     plan to
>>     >> > allow users to pretend GHC has a unified namespace. That is,
>>     suppose x
>>     >> > is in scope as a term variable, and then we have f (... ::
>>     ... x ...) =
>>     >> > ... . Should that x be bound implicitly there or not? It's
>>     pretty
>>     >> > unclear. By separating out -XPatternSignatureBinds from
>>     >> > -XPatternSignatures, users of the latter are insulated from
>>     worrying
>>     >> > about this potential future change.
>>     >> >
>>     >> > My opinion:
>>     >> >
>>     >> > - John has argued that this will make future namespace
>>     changes easier.
>>     >> > I disagree with this assessment, because
>>     -XScopedTypeVariables is
>>     >> > utterly pervasive. So the problem that this change is
>>     supposed to solve
>>     >> > becomes only a tiny bit smaller, benefiting only those users who
>>     >> > carefully enable -XPatternSignatures but not, say,
>>     >> > -XScopedTypeVariables.
>>     >> > - But in the end, I don't care all that much. I've come to
>>     the opinion
>>     >> > that we shouldn't worry about the distinction between
>>     warnings and
>>     >> > extensions. The net effect of this proposal is to promote a
>>     warning
>>     >> > into an extension (because we previously had
>>     >> > -Wpattern-signature-binds). So if we shouldn't worry about this
>>     >> > distinction, then this proposal is a no-op on the aspects of the
>>     >> > language we should care about, and thus accepting and
>>     rejecting have
>>     >> > the same effect. (This little analysis only makes sense
>>     because the
>>     >> > features are so new -- there's no broad re-education to do or
>>     >> > back-compat issues.)
>>     >> > - Accepting will make at least one person (John) happy. And I
>>     don't
>>     >> > note anyone who would become unhappy. More happy people is
>>     more better.
>>     >> > So I recommend acceptance. :)
>>     >> >
>>     >> > Please let us know your thoughts!
>>     >> > Richard


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From mail at joachim-breitner.de  Mon Jan 29 08:06:54 2024
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 29 Jan 2024 09:06:54 +0100
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <A36D6E9A-B7DC-49A2-9D8C-D69EA4E13368@seidel.io>
References: <CAJKmMz_UPvpuEub5Q=3j7CbCyr1fMbwGkOBCF+F3vq9eahaRxQ@mail.gmail.com>
 <A36D6E9A-B7DC-49A2-9D8C-D69EA4E13368@seidel.io>
Message-ID: <a7ab7aae9db5380f2f1760bee22dacee0751f1dc.camel@joachim-breitner.de>

Hi,

I had to peek at
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst
to remind myself whether the “Local Lexical Scoping Principle” (every
mention of a variable is clearly a binder or a reference) was part of
that, or just the “Lexical Scoping Principle” is. Turns out the LLSP
isn’t part of it. But I have a vague memory that the LSP together with
the SUP is much easier when we have the LLSP?

Anyways, partly because of the dubious status and future of
ScopedTypeVariables, as a user I found myself wanting to enable the
simple part of pattern binds (do `xs :: String ← …`) without enable
other parts of that extension.

Cheers,
Joachim




Am Sonntag, dem 28.01.2024 um 18:50 -0600 schrieb Eric Seidel:
> Yep that’s the question. 
> 
> If we were starting from scratch I would agree that B is better. But I worry that there may be a lot of code out there that expects A.
> 
> So then this becomes a question of tradeoffs, is the simplification benefit of this change sufficient to justify the migration cost we may be imposing on the community? 
> 
> It seems unlikely to me.
> 
> Sent from my iPhone
> 
> > On Jan 28, 2024, at 12:22, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> > 
> > > When I review a proposal for a new extension, one of the
> > > questions I ask myself is "would I eventually support including this in
> > > a GHC20xx standard?" If the answer is no (and if the extension is not one
> > > of the advanced or niche things like CPP), then I'm much less likely to
> > > support it.
> > 
> > Aha.  Now I understand your point thanks.
> > 
> > In the glorious future, what do we want?
> >  * Plan A.   "A pattern signature brings into scope any variables that aren't already in scope".  It's a bit of a tricky rule. If we see `f (Just x) = rhs` we know that it brings `x` into scope regardless.  Simple.  No so with pattern-signatures!
> >    
> >  * Plan B.   Pattern signatures never bring anything into scope.  To do that, use @type patterns.  For example, instead of
> >        f (Just (x::a)) = rhs
> >    say
> >        f (Just @a x) = rhs
> >    Now it's clear that `a` is being brought into scope.
> > I lean towards Plan B, but you raise a good point.  I'd love to know what our consensus is.   RSVP steering committee members.
> > 
> > Simon
> > 
> > On Sun, 28 Jan 2024 at 00:12, Eric Seidel <eric at seidel.io> wrote:
> > > I think it's mostly a philosophical point. We have GHC2021 which is the
> > > current "blessed" version of the language. It includes ScopedTypeVariables,
> > > which if I understand correctly is a superset of PatternSigs. We also want
> > > to move in the direction of having *fewer* interacting extensions. In my
> > > mind that is one of the main motivations for introducing the GHC20xx
> > > standards. When I review a proposal for a new extension, one of the
> > > questions I ask myself is "would I eventually support including this in
> > > a GHC20xx standard?" If the answer is no (and if the extension is not one
> > > of the advanced or niche things like CPP), then I'm much less likely to
> > > support it.
> > > 
> > > So what is the purpose of refactoring extensions that are implied by
> > > ScopedTypeVariables? It seems like needless churn if ScopedTypeVariables
> > > is here to stay. On the other hand, if we mean to change ScopedTypeVariables
> > > we should be explicit about that. 
> > > 
> > > On Sat, Jan 27, 2024, at 16:56, Simon Peyton Jones wrote:
> > > > To me this looks uncontroversial.  
> > > >   • We have a currently-deprecated extension -XPatternSignatures
> > > >   • This proposal rehabilitates it (with a narrower scope than before) 
> > > > and adds a new one -XPatternSignatureBinds
> > > >   • If you don't use these extensions they won't harm you
> > > >   • The behaviour of -XScopedTypeVariables is unchanged
> > > > It's a fairly tiny thing, easy to implement, easy to document.  I don't 
> > > > care very much, but I'm content to approve it.
> > > > 
> > > > My only regret is that we don't have a "warning form" for language 
> > > > extensions (see 
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/620) . I'd like to 
> > > > say -WPatternSignatureBinds, meaning to allow pattern-signatures to 
> > > > bind, but warn on every such occasion.  Lacking such a "warning form" 
> > > > we have to *also* have `-Wpattern-signature-binds`.
> > > > 
> > > > Eric, I'm not sure what specifically you are objecting to.  Are you 
> > > > making a philosophical point, or is there active harm here?
> > > > 
> > > > Simon
> > > > 
> > > > On Sat, 27 Jan 2024 at 19:44, Eric Seidel <eric at seidel.io> wrote:
> > > > > The motivation for this change does not make sense to me. ScopedTypeVariables
> > > > > is used everywhere and is even part of GHC2021. The goal of this change appears
> > > > > to be to extract out a controversial piece of PatternSignatures such that it
> > > > > could be later removed entirely, but without addressing the issue of
> > > > > ScopedTypeVariables.
> > > > > 
> > > > > That's going about it the wrong way IMO. If we want to remove the behavior
> > > > > this proposal calls PatternSignatureBinds, the Committee should first adopt
> > > > > a resolution that we will remove (or alter the meaning of) ScopedTypeVariables
> > > > > in the next GHC20xx. If we get agreement on that, then this proposal could make
> > > > > sense as a step towards the broader goal.
> > > > > 
> > > > > Outside of that broader agreement though, this feels more like a fork-inducing
> > > > > proposal and I would vote against.
> > > > > 
> > > > > On Wed, Jan 24, 2024, at 11:32, Richard Eisenberg wrote:
> > > > > > John Ericson has submitted proposal #608 
> > > > > > <https://github.com/ghc-proposals/ghc-proposals/pull/608> about adding 
> > > > > > -XPatternSignatureBinds. The proposal is an amendment and is thus a 
> > > > > > little harder to consume. I recommend reading the summary here.
> > > > > > 
> > > > > > Proposed change:
> > > > > > 
> > > > > > The proposed -XPatternSignatureBinds takes a piece out from 
> > > > > > -XPatternSignatures: with only -XPatternSignatures and not 
> > > > > > -XPatternSignatureBinds, a pattern signature  can mention in-scope type 
> > > > > > variables but can never bind fresh ones. With -XPatternSignatureBinds, 
> > > > > > an appearance of an out-of-scope type variable in a pattern signature 
> > > > > > will cause the variable to be bound to the type it unifies with.
> > > > > > 
> > > > > > -XScopedTypeVariables will imply -XPatternSignatures 
> > > > > > -XPatternSignatureBinds (and a few more), so the behavior of 
> > > > > > -XScopedTypeVariables is completely unchanged. Note that 
> > > > > > -XPatternSignatures is currently deprecated (and has been so for a long 
> > > > > > time), so a change in behavior there is not so bad.
> > > > > > 
> > > > > > Motivation for the change:
> > > > > > 
> > > > > > - It is awkward to have a rule in a language where scoping behavior 
> > > > > > depends on what else is in scope. This can confound e.g. tools meant to 
> > > > > > find the bindings sites of a variable occurrence.
> > > > > > - The implicit binding we have today plays poorly with the plan to 
> > > > > > allow users to pretend GHC has a unified namespace. That is, suppose x 
> > > > > > is in scope as a term variable, and then we have f (... :: ... x ...) = 
> > > > > > ... . Should that x be bound implicitly there or not? It's pretty 
> > > > > > unclear. By separating out -XPatternSignatureBinds from 
> > > > > > -XPatternSignatures, users of the latter are insulated from worrying 
> > > > > > about this potential future change.
> > > > > > 
> > > > > > My opinion:
> > > > > > 
> > > > > > - John has argued that this will make future namespace changes easier. 
> > > > > > I disagree with this assessment, because -XScopedTypeVariables is 
> > > > > > utterly pervasive. So the problem that this change is supposed to solve 
> > > > > > becomes only a tiny bit smaller, benefiting only those users who 
> > > > > > carefully enable -XPatternSignatures but not, say, 
> > > > > > -XScopedTypeVariables.
> > > > > > - But in the end, I don't care all that much. I've come to the opinion 
> > > > > > that we shouldn't worry about the distinction between warnings and 
> > > > > > extensions. The net effect of this proposal is to promote a warning 
> > > > > > into an extension (because we previously had 
> > > > > > -Wpattern-signature-binds). So if we shouldn't worry about this 
> > > > > > distinction, then this proposal is a no-op on the aspects of the 
> > > > > > language we should care about, and thus accepting and rejecting have 
> > > > > > the same effect. (This little analysis only makes sense because the 
> > > > > > features are so new -- there's no broad re-education to do or 
> > > > > > back-compat issues.)
> > > > > > - Accepting will make at least one person (John) happy. And I don't 
> > > > > > note anyone who would become unhappy. More happy people is more better. 
> > > > > > So I recommend acceptance. :)
> > > > > > 
> > > > > > Please let us know your thoughts!
> > > > > > Richard
> > > > > > _______________________________________________
> > > > > > ghc-steering-committee mailing list
> > > > > > ghc-steering-committee at haskell.org
> > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > > _______________________________________________
> > > > > ghc-steering-committee mailing list
> > > > > ghc-steering-committee at haskell.org
> > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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


From arnaud.spiwack at tweag.io  Mon Jan 29 09:24:18 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 29 Jan 2024 10:24:18 +0100
Subject: [ghc-steering-committee] Please review #631: Set program exit
 code by main return type, Shepherd: Arnaud
In-Reply-To: <d89aa1d0-59ff-4a1c-b460-8bd2803fae25@well-typed.com>
References: <d89aa1d0-59ff-4a1c-b460-8bd2803fae25@well-typed.com>
Message-ID: <CAGwnsnm49Fa4mNyPHTmM36ZHx+v4oEXJYJaNHazdoDKg1e5gHw@mail.gmail.com>

I can be the shepherd, but, full disclosure: Shea is my colleague at Tweag.

On Sat, 27 Jan 2024 at 21:15, Adam Gundry <adam at well-typed.com> wrote:

> Dear Committee,
>
> Shea Levy proposes that the value returned by `main` should determine
> the exit code of the program:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/631
>
>
> https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst
>
> I'd like to nominate Arnaud as the shepherd.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Cheers,
>
> Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/aa44a589/attachment.html>

From simon.peytonjones at gmail.com  Mon Jan 29 09:35:32 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 29 Jan 2024 09:35:32 +0000
Subject: [ghc-steering-committee] Proposal #612: Change semantics of
 -fhpc to not accumulate data over multiple runs, rec: accept
In-Reply-To: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
References: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
Message-ID: <CAJKmMz-=ze+cUbaK9Z36j-96B-orQkwCVaJVrH9zfzMfihrC1A@mail.gmail.com>

The change itself makes sense to me, non-accumulating semantics seem like
a much better default.


I strongly agree with this.  The current behaviour seems deeply strange,
and the proposer offers evidence that it messes up users.

As to deprecation, how about this:

   - In the first release, GHC continues with the current behaviour, but
   *if* it finds an old file (of any kind, even in the wrong format) it emits
   a warning (before attempting to read it) saying

*I am reading in the existing tix file, and will add hpc info from this run
to the existing data in that file.  GHC 9.12 will cease looking for an
existing tix file.  If you positively want to add hpc info to the current
tix file, use `-fread-tix-file`*

   - In the next release, it stops reading the file

That is not onerous to implement, but it gives due warning.  Moreover, you
can respond right away by saying `-fno-read-tix-file` or `-fread-tix-file`
to avoid the warning.

Simon says

I don't think a deprecation warning resolves the concern
>

That's true of all deprecation warnings -- there will always be users who
ignore them.  But we have done our duty by, well, warning them.

Simon

On Thu, 25 Jan 2024 at 06:06, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Dear Committee members,
>
> In Proposal #612 <https://github.com/ghc-proposals/ghc-proposals/pull/612>,
> David Binder suggests changing the semantics from `-fhpc` to auto-ingest
> existing .tix files for accumulation, towards _not_ auto-ingesting them
> and instead overwriting
> the .tix file with the coverage of the latest run.
>
> I agree with his assessment that the current behaviour easily leads to
> unexpected surprises. He suggests adding a flag --read-tix-file= to control
> this behaviour and defaulting that to _no_, with a grace and
> deprecation period prior informing the user that the currently accumulating
> feature will change in a future GHC release.
>
> Adding the flag to control this behaviour is fairly uncontroversial I
> hope, however I'd like you to. Weight in on the default. Should we change
> the default behaviour, or only add the flag?
>
> I'd recommend changing the default to --read-tix-file=no after a
> deprecation period.
>
> Best,
>  Moritz
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/791ce142/attachment.html>

From arnaud.spiwack at tweag.io  Mon Jan 29 09:36:01 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 29 Jan 2024 10:36:01 +0100
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <493eed2d-3b29-46bf-bd55-58e97980c901@well-typed.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <23fb994ab7c5c9ca63eac19ddcfc40d6055d4ed7.camel@joachim-breitner.de>
 <12323e8d-0b7d-4263-98ff-df88fbd81665@well-typed.com>
 <CAKfdd-zewu2v+TcV1JGJv=+E-S1FZiOTG9wrM9EPGvsrxuDABw@mail.gmail.com>
 <CAGwnsnnR4B1Ns8MzXUn7Xpy1e5f-=uYQ491z1W6V6Wf77jcQpQ@mail.gmail.com>
 <CALkkMoT-vp=PnCE2tzWzfbTY07-tnS2GvBd8MKzCNt_k7d2b5A@mail.gmail.com>
 <CAGwnsnn=J9z-yTpHC8eSd4tgacx64OErKXuFaWe=Bv9c=+LKyA@mail.gmail.com>
 <CALkkMoSvJGgM=95VR3EKs_yGa1Uf2J6SZ06BZcuDX-tb_av5oQ@mail.gmail.com>
 <493eed2d-3b29-46bf-bd55-58e97980c901@well-typed.com>
Message-ID: <CAGwnsnkZrFqKWQSU_Eh3MNijbGg2TsSHZ0ZEMxVWw-=AwTqq4Q@mail.gmail.com>

On Fri, 26 Jan 2024 at 21:14, Adam Gundry <adam at well-typed.com> wrote:

> I would argue that we should be willing to remove (mis)features from
> future GHC20xx editions, and that (the PatternSignatureBinds component
> of) ScopedTypeVariables is potentially such a misfeature.
>

I agree (in fact, I'd say that it's the whole point of language editions).
Hence my question :-) .

I don't, however, agree that we should make arguments on the grounds of the
swiss-army-knife philosophy (“make it possible to customise GHC to
everybody's desires”). I think that 2023 has been a convincing
demonstration that this philosophy hasn't served us well, and has been
counterproductive. Actually, I was under the impression that all the
discourse about basing our stability guarantees on language editions was a
definite adoption of the newer point of view. It does seem, though, that
we're not yet in complete agreement there.

I'm content to concede here, but you'll have noticed in my recent
interventions that I'm increasingly prudent about entropy-increasing
changes (I'm worried, I guess, about death by a thousand paper cuts). I'd
rather changes that we accept have a purpose. Does this one have a purpose?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/114eb716/attachment.html>

From arnaud.spiwack at tweag.io  Mon Jan 29 09:42:14 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 29 Jan 2024 10:42:14 +0100
Subject: [ghc-steering-committee] Proposal #612: Change semantics of
 -fhpc to not accumulate data over multiple runs, rec: accept
In-Reply-To: <CAJKmMz-=ze+cUbaK9Z36j-96B-orQkwCVaJVrH9zfzMfihrC1A@mail.gmail.com>
References: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
 <CAJKmMz-=ze+cUbaK9Z36j-96B-orQkwCVaJVrH9zfzMfihrC1A@mail.gmail.com>
Message-ID: <CAGwnsn=KO_JwDZRzkEkNx67gQgnNYSgg45nd+bBCU2uGsjvqZA@mail.gmail.com>

For the record, I'm fine either way.

On Mon, 29 Jan 2024 at 10:35, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> The change itself makes sense to me, non-accumulating semantics seem like
> a much better default.
>
>
> I strongly agree with this.  The current behaviour seems deeply strange,
> and the proposer offers evidence that it messes up users.
>
> As to deprecation, how about this:
>
>    - In the first release, GHC continues with the current behaviour, but
>    *if* it finds an old file (of any kind, even in the wrong format) it emits
>    a warning (before attempting to read it) saying
>
> *I am reading in the existing tix file, and will add hpc info from this
> run to the existing data in that file.  GHC 9.12 will cease looking for an
> existing tix file.  If you positively want to add hpc info to the current
> tix file, use `-fread-tix-file`*
>
>    - In the next release, it stops reading the file
>
> That is not onerous to implement, but it gives due warning.  Moreover, you
> can respond right away by saying `-fno-read-tix-file` or `-fread-tix-file`
> to avoid the warning.
>
> Simon says
>
> I don't think a deprecation warning resolves the concern
>>
>
> That's true of all deprecation warnings -- there will always be users who
> ignore them.  But we have done our duty by, well, warning them.
>
> Simon
>
> On Thu, 25 Jan 2024 at 06:06, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> Dear Committee members,
>>
>> In Proposal #612
>> <https://github.com/ghc-proposals/ghc-proposals/pull/612>, David Binder
>> suggests changing the semantics from `-fhpc` to auto-ingest
>> existing .tix files for accumulation, towards _not_ auto-ingesting them
>> and instead overwriting
>> the .tix file with the coverage of the latest run.
>>
>> I agree with his assessment that the current behaviour easily leads to
>> unexpected surprises. He suggests adding a flag --read-tix-file= to control
>> this behaviour and defaulting that to _no_, with a grace and
>> deprecation period prior informing the user that the currently accumulating
>> feature will change in a future GHC release.
>>
>> Adding the flag to control this behaviour is fairly uncontroversial I
>> hope, however I'd like you to. Weight in on the default. Should we change
>> the default behaviour, or only add the flag?
>>
>> I'd recommend changing the default to --read-tix-file=no after a
>> deprecation period.
>>
>> Best,
>>  Moritz
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/090b9d8b/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Jan 29 09:46:54 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 29 Jan 2024 09:46:54 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <CAGwnsnkZrFqKWQSU_Eh3MNijbGg2TsSHZ0ZEMxVWw-=AwTqq4Q@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <23fb994ab7c5c9ca63eac19ddcfc40d6055d4ed7.camel@joachim-breitner.de>
 <12323e8d-0b7d-4263-98ff-df88fbd81665@well-typed.com>
 <CAKfdd-zewu2v+TcV1JGJv=+E-S1FZiOTG9wrM9EPGvsrxuDABw@mail.gmail.com>
 <CAGwnsnnR4B1Ns8MzXUn7Xpy1e5f-=uYQ491z1W6V6Wf77jcQpQ@mail.gmail.com>
 <CALkkMoT-vp=PnCE2tzWzfbTY07-tnS2GvBd8MKzCNt_k7d2b5A@mail.gmail.com>
 <CAGwnsnn=J9z-yTpHC8eSd4tgacx64OErKXuFaWe=Bv9c=+LKyA@mail.gmail.com>
 <CALkkMoSvJGgM=95VR3EKs_yGa1Uf2J6SZ06BZcuDX-tb_av5oQ@mail.gmail.com>
 <493eed2d-3b29-46bf-bd55-58e97980c901@well-typed.com>
 <CAGwnsnkZrFqKWQSU_Eh3MNijbGg2TsSHZ0ZEMxVWw-=AwTqq4Q@mail.gmail.com>
Message-ID: <CAJKmMz_D2+8iJkG0gk9BkoB4gssCxfpnf6S6W1UNsCJo7nuRoA@mail.gmail.com>

Does this one have a purpose?


Well, yes.   It allows people who want pattern signatures that do not bind
to have pattern signatures that do not bind.

Given that it is easy to specify, and easy to implement, I'm inclined to
give them their wishes.

Having lots of combinations be possible (for users who care to specify
them), as GHC has historically done, is fully compatible with language
editions that embody a particular set of choices.   I like language
editions, but I don't see them as a reason to restrict choice.

(If it was hard to implement something that would be a strike against
choice; but that's not at issue here.)

I don't think this particular issue is worth burning many cycles over :-).
Let's just accept and move on.

Simon

On Mon, 29 Jan 2024 at 09:36, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> On Fri, 26 Jan 2024 at 21:14, Adam Gundry <adam at well-typed.com> wrote:
>
>> I would argue that we should be willing to remove (mis)features from
>> future GHC20xx editions, and that (the PatternSignatureBinds component
>> of) ScopedTypeVariables is potentially such a misfeature.
>>
>
> I agree (in fact, I'd say that it's the whole point of language editions).
> Hence my question :-) .
>
> I don't, however, agree that we should make arguments on the grounds of
> the swiss-army-knife philosophy (“make it possible to customise GHC to
> everybody's desires”). I think that 2023 has been a convincing
> demonstration that this philosophy hasn't served us well, and has been
> counterproductive. Actually, I was under the impression that all the
> discourse about basing our stability guarantees on language editions was a
> definite adoption of the newer point of view. It does seem, though, that
> we're not yet in complete agreement there.
>
> I'm content to concede here, but you'll have noticed in my recent
> interventions that I'm increasingly prudent about entropy-increasing
> changes (I'm worried, I guess, about death by a thousand paper cuts). I'd
> rather changes that we accept have a purpose. Does this one have a purpose?
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/f2fca094/attachment.html>

From marlowsd at gmail.com  Mon Jan 29 11:03:12 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 29 Jan 2024 11:03:12 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>

I might be a bit confused, but doesn't this proposal change the meaning of
an existing extension (PatternSignatures)? In which case shouldn't we do it
properly according to our stability principles and either introduce the new
behaviour as a new extension, or restrict the change to GHC2024 and later
only?

Cheers
Simon

On Wed, 24 Jan 2024 at 17:33, Richard Eisenberg <rae at richarde.dev> wrote:

> John Ericson has submitted proposal #608
> <https://github.com/ghc-proposals/ghc-proposals/pull/608> about adding
> -XPatternSignatureBinds. The proposal is an amendment and is thus a little
> harder to consume. I recommend reading the summary here.
>
> Proposed change:
>
> The proposed -XPatternSignatureBinds takes a piece out from
> -XPatternSignatures: with only -XPatternSignatures and not
> -XPatternSignatureBinds, a pattern signature  can mention in-scope type
> variables but can never bind fresh ones. With -XPatternSignatureBinds, an
> appearance of an out-of-scope type variable in a pattern signature will
> cause the variable to be bound to the type it unifies with.
>
> -XScopedTypeVariables will imply -XPatternSignatures
> -XPatternSignatureBinds (and a few more), so the behavior of
> -XScopedTypeVariables is completely unchanged. Note that
> -XPatternSignatures is currently deprecated (and has been so for a long
> time), so a change in behavior there is not so bad.
>
> Motivation for the change:
>
> - It is awkward to have a rule in a language where scoping behavior
> depends on what else is in scope. This can confound e.g. tools meant to
> find the bindings sites of a variable occurrence.
> - The implicit binding we have today plays poorly with the plan to allow
> users to pretend GHC has a unified namespace. That is, suppose x is in
> scope as a term variable, and then we have f (... :: ... x ...) = ... .
> Should that x be bound implicitly there or not? It's pretty unclear. By
> separating out -XPatternSignatureBinds from -XPatternSignatures, users of
> the latter are insulated from worrying about this potential future change.
>
> My opinion:
>
> - John has argued that this will make future namespace changes easier. I
> disagree with this assessment, because -XScopedTypeVariables is utterly
> pervasive. So the problem that this change is supposed to solve becomes
> only a tiny bit smaller, benefiting only those users who carefully enable
> -XPatternSignatures but not, say, -XScopedTypeVariables.
> - But in the end, I don't care all that much. I've come to the opinion
> that we shouldn't worry about the distinction between warnings and
> extensions. The net effect of this proposal is to promote a warning into an
> extension (because we previously had -Wpattern-signature-binds). So if we
> shouldn't worry about this distinction, then this proposal is a no-op on
> the aspects of the language we should care about, and thus accepting and
> rejecting have the same effect. (This little analysis only makes sense
> because the features are so new -- there's no broad re-education to do or
> back-compat issues.)
> - Accepting will make at least one person (John) happy. And I don't note
> anyone who would become unhappy. More happy people is more better. So I
> recommend acceptance. :)
>
> Please let us know your thoughts!
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/df2382ad/attachment.html>

From mail at joachim-breitner.de  Mon Jan 29 11:15:31 2024
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 29 Jan 2024 12:15:31 +0100
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
Message-ID: <7ee154a4cc3b782b8f40cbe57b2af0f46deea85d.camel@joachim-breitner.de>

Hi,

Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:
> I might be a bit confused, but doesn't this proposal change the meaning of an existing
> extension (PatternSignatures)?

a long-ago deprecated one:

~ $ ghci
GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
ghci> :set -XPatternSignatures

<no location info>: warning: [-Wdeprecated-flags]
    -XPatternSignatures is deprecated: use -XScopedTypeVariables or pragma {-# LANGUAGE ScopedTypeVariables #-} instead

Hopefully our stability principles does not require us to heed programs
that ignored deprecation flags for a while?

My understanding of
https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles
is that, despite “stable package” not saying “does not use features
deprecated long ago”, it’s still ok to break such programs, as this is
our mechanism GR3?


Of course we could side-step this procedural question about repurposing
an old extension and introduce `SimplePatternSignatures` instead. Not
in favor, simply because as a user I more than once intuitively reached
for `PatternSignatures` to get the proposed behavior.

Cheers,
Joachim


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


From marlowsd at gmail.com  Mon Jan 29 11:32:44 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 29 Jan 2024 11:32:44 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <7ee154a4cc3b782b8f40cbe57b2af0f46deea85d.camel@joachim-breitner.de>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
 <7ee154a4cc3b782b8f40cbe57b2af0f46deea85d.camel@joachim-breitner.de>
Message-ID: <CANsrgPLZ8_eDPk7dHDuWNjVKiONAphJo4r0HjR9WDmOCoB9Jrw@mail.gmail.com>

"Only exceptionally would we fix a design flaw in a way that breaks
programs compiled with existing language editions."
https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2

This is not exceptional is it? It's just a regular design flaw :) If we
must fix it, let's do it in a way that complies with the stability
principle.

Cheers
Simon


On Mon, 29 Jan 2024 at 11:15, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:
> > I might be a bit confused, but doesn't this proposal change the meaning
> of an existing
> > extension (PatternSignatures)?
>
> a long-ago deprecated one:
>
> ~ $ ghci
> GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
> ghci> :set -XPatternSignatures
>
> <no location info>: warning: [-Wdeprecated-flags]
>     -XPatternSignatures is deprecated: use -XScopedTypeVariables or pragma
> {-# LANGUAGE ScopedTypeVariables #-} instead
>
> Hopefully our stability principles does not require us to heed programs
> that ignored deprecation flags for a while?
>
> My understanding of
>
> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles
> is that, despite “stable package” not saying “does not use features
> deprecated long ago”, it’s still ok to break such programs, as this is
> our mechanism GR3?
>
>
> Of course we could side-step this procedural question about repurposing
> an old extension and introduce `SimplePatternSignatures` instead. Not
> in favor, simply because as a user I more than once intuitively reached
> for `PatternSignatures` to get the proposed behavior.
>
> Cheers,
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/b942130b/attachment.html>

From mail at joachim-breitner.de  Mon Jan 29 11:41:47 2024
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 29 Jan 2024 12:41:47 +0100
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <CANsrgPLZ8_eDPk7dHDuWNjVKiONAphJo4r0HjR9WDmOCoB9Jrw@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
 <7ee154a4cc3b782b8f40cbe57b2af0f46deea85d.camel@joachim-breitner.de>
 <CANsrgPLZ8_eDPk7dHDuWNjVKiONAphJo4r0HjR9WDmOCoB9Jrw@mail.gmail.com>
Message-ID: <14dbafad95a577f2f4905a6ee793b23c67bda4d2.camel@joachim-breitner.de>

Hi,

well, we were more liberal at deprecating things in the past than we
will be under the new regime, and we might not have invoked GR2 here.

But the extension already _is_ deprecated. If deprecating (even for the
wrong reasons) and waiting multiple releases does not allow us to break
the deprecated thing, then what is the point of GR3?

I am quite fond of the new stability regime, it sets out
clear requirements on code (set a language flag, heed deprecation
warnings, although the latter could be spelled out more explicitly), in
return for clear promises. Let’s not water this down by not taking the
set of requirements of requirements seriously ourselves.

Cheers,
Joachim

Am Montag, dem 29.01.2024 um 11:32 +0000 schrieb Simon Marlow:
> "Only exceptionally would we fix a design flaw in a way that breaks programs compiled with existing language editions." https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2
> 
> This is not exceptional is it? It's just a regular design flaw :) If we must fix it, let's do it in a way that complies with the stability principle.
> 
> Cheers
> Simon
> 
> 
> On Mon, 29 Jan 2024 at 11:15, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > Hi,
> > 
> > Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:
> > > I might be a bit confused, but doesn't this proposal change the meaning of an existing
> > > extension (PatternSignatures)?
> > 
> > a long-ago deprecated one:
> > 
> > ~ $ ghci
> > GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
> > ghci> :set -XPatternSignatures
> > 
> > <no location info>: warning: [-Wdeprecated-flags]
> >     -XPatternSignatures is deprecated: use -XScopedTypeVariables or pragma {-# LANGUAGE ScopedTypeVariables #-} instead
> > 
> > Hopefully our stability principles does not require us to heed programs
> > that ignored deprecation flags for a while?
> > 
> > My understanding of
> > https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles
> > is that, despite “stable package” not saying “does not use features
> > deprecated long ago”, it’s still ok to break such programs, as this is
> > our mechanism GR3?
> > 
> > 
> > Of course we could side-step this procedural question about repurposing
> > an old extension and introduce `SimplePatternSignatures` instead. Not
> > in favor, simply because as a user I more than once intuitively reached
> > for `PatternSignatures` to get the proposed behavior.
> > 
> > Cheers,
> > Joachim
> > 
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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


From marlowsd at gmail.com  Mon Jan 29 13:07:18 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 29 Jan 2024 13:07:18 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <14dbafad95a577f2f4905a6ee793b23c67bda4d2.camel@joachim-breitner.de>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
 <7ee154a4cc3b782b8f40cbe57b2af0f46deea85d.camel@joachim-breitner.de>
 <CANsrgPLZ8_eDPk7dHDuWNjVKiONAphJo4r0HjR9WDmOCoB9Jrw@mail.gmail.com>
 <14dbafad95a577f2f4905a6ee793b23c67bda4d2.camel@joachim-breitner.de>
Message-ID: <CANsrgP+nvhWn4KPoLewWKbShiUnaUKF_2cUUDDVdwuN-ZEs-uA@mail.gmail.com>

Hmm, deciding that the stability principles don't apply to pre-existing
deprecations would not be in the right spirit, if you ask me. I think we
should apply the rules consistently to every proposal going forward, being
already deprecated doesn't get you a pass. In this case we really don't
have to break existing code, so let's not do it.

It's not that hard to make a new extension or to change the behaviour in
GHC2024 is it?

Cheers
Simon



On Mon, 29 Jan 2024 at 11:42, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> well, we were more liberal at deprecating things in the past than we
> will be under the new regime, and we might not have invoked GR2 here.
>
> But the extension already _is_ deprecated. If deprecating (even for the
> wrong reasons) and waiting multiple releases does not allow us to break
> the deprecated thing, then what is the point of GR3?
>
> I am quite fond of the new stability regime, it sets out
> clear requirements on code (set a language flag, heed deprecation
> warnings, although the latter could be spelled out more explicitly), in
> return for clear promises. Let’s not water this down by not taking the
> set of requirements of requirements seriously ourselves.
>
> Cheers,
> Joachim
>
> Am Montag, dem 29.01.2024 um 11:32 +0000 schrieb Simon Marlow:
> > "Only exceptionally would we fix a design flaw in a way that breaks
> programs compiled with existing language editions."
> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2
> >
> > This is not exceptional is it? It's just a regular design flaw :) If we
> must fix it, let's do it in a way that complies with the stability
> principle.
> >
> > Cheers
> > Simon
> >
> >
> > On Mon, 29 Jan 2024 at 11:15, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> > > Hi,
> > >
> > > Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:
> > > > I might be a bit confused, but doesn't this proposal change the
> meaning of an existing
> > > > extension (PatternSignatures)?
> > >
> > > a long-ago deprecated one:
> > >
> > > ~ $ ghci
> > > GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
> > > ghci> :set -XPatternSignatures
> > >
> > > <no location info>: warning: [-Wdeprecated-flags]
> > >     -XPatternSignatures is deprecated: use -XScopedTypeVariables or
> pragma {-# LANGUAGE ScopedTypeVariables #-} instead
> > >
> > > Hopefully our stability principles does not require us to heed programs
> > > that ignored deprecation flags for a while?
> > >
> > > My understanding of
> > >
> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles
> > > is that, despite “stable package” not saying “does not use features
> > > deprecated long ago”, it’s still ok to break such programs, as this is
> > > our mechanism GR3?
> > >
> > >
> > > Of course we could side-step this procedural question about repurposing
> > > an old extension and introduce `SimplePatternSignatures` instead. Not
> > > in favor, simply because as a user I more than once intuitively reached
> > > for `PatternSignatures` to get the proposed behavior.
> > >
> > > Cheers,
> > > Joachim
> > >
> > >
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/282de1e6/attachment.html>

From reisenberg at janestreet.com  Mon Jan 29 13:56:20 2024
From: reisenberg at janestreet.com (Richard Eisenberg)
Date: Mon, 29 Jan 2024 08:56:20 -0500
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds.  Rec: accept
In-Reply-To: <CANsrgP+nvhWn4KPoLewWKbShiUnaUKF_2cUUDDVdwuN-ZEs-uA@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
 <7ee154a4cc3b782b8f40cbe57b2af0f46deea85d.camel@joachim-breitner.de>
 <CANsrgPLZ8_eDPk7dHDuWNjVKiONAphJo4r0HjR9WDmOCoB9Jrw@mail.gmail.com>
 <14dbafad95a577f2f4905a6ee793b23c67bda4d2.camel@joachim-breitner.de>
 <CANsrgP+nvhWn4KPoLewWKbShiUnaUKF_2cUUDDVdwuN-ZEs-uA@mail.gmail.com>
Message-ID: <CALkkMoR=aALOYAmit8t42t_duj--mW-se-qGkNb5K5zXVtRUVA@mail.gmail.com>

Responding to a few points above:

Simon PJ:


Does this one have a purpose?


Well, yes.   It allows people who want pattern signatures that do not bind
to have pattern signatures that do not bind.

But this already exists; it's called -Werror=pattern-signature-binds. So
this proposal adds no new expressiveness. It just changes a warning to be
an extension.

Adam:

I respectfully disagree with Richard's characterisation of
this proposal as merely promoting a warning to be an extension. [See
https://gist.github.com/adamgundry/5446f390ee84254c43a0425e821dc930]

Your example indeed demonstrates that -XScopedTypeVariables is
non-conservative, but it is silent on pattern signature bindings. My
enthusiasm for my warning-to-extension claim remains, unabated. (But please
do keep trying to convince!)

Simon M:

deciding that the stability principles don't apply to pre-existing
deprecations would not be in the right spirit, if you ask me


To me, it's in the spirit of "deprecation", if not stability. That is, what
does it mean to deprecate a feature? I think it means that users should
expect the feature to disappear at some point in the future; in other
words, it explicitly labels a feature as non-stable. Up until now, we
hadn't settled on a meaning of stability, and so by extension we hadn't
settled on a meaning for deprecation. So maybe we say "the feature wasn't
actually deprecated because we didn't know what *deprecated* meant", but I
think this one has been labeled deprecated for long enough that we should
feel comfortable removing it / changing it.

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

My initial support for this proposal was based on the fact that it made a
few people happy. Now it's become clear that it also makes a few people
unhappy. I'm still hoping for a language-edition-based future
<https://github.com/ghc-proposals/ghc-proposals/pull/628> where this
proposal doesn't matter, so I'm pretty agnostic. Maybe on balance it's a
better use of time debating that potential future (I'll prepare a proper
proposal this week) than to debate this finer point?

Richard

On Mon, Jan 29, 2024 at 8:07 AM Simon Marlow <marlowsd at gmail.com> wrote:

> Hmm, deciding that the stability principles don't apply to pre-existing
> deprecations would not be in the right spirit, if you ask me. I think we
> should apply the rules consistently to every proposal going forward, being
> already deprecated doesn't get you a pass. In this case we really don't
> have to break existing code, so let's not do it.
>
> It's not that hard to make a new extension or to change the behaviour in
> GHC2024 is it?
>
> Cheers
> Simon
>
>
>
> On Mon, 29 Jan 2024 at 11:42, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> well, we were more liberal at deprecating things in the past than we
>> will be under the new regime, and we might not have invoked GR2 here.
>>
>> But the extension already _is_ deprecated. If deprecating (even for the
>> wrong reasons) and waiting multiple releases does not allow us to break
>> the deprecated thing, then what is the point of GR3?
>>
>> I am quite fond of the new stability regime, it sets out
>> clear requirements on code (set a language flag, heed deprecation
>> warnings, although the latter could be spelled out more explicitly), in
>> return for clear promises. Let’s not water this down by not taking the
>> set of requirements of requirements seriously ourselves.
>>
>> Cheers,
>> Joachim
>>
>> Am Montag, dem 29.01.2024 um 11:32 +0000 schrieb Simon Marlow:
>> > "Only exceptionally would we fix a design flaw in a way that breaks
>> programs compiled with existing language editions."
>> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2
>> >
>> > This is not exceptional is it? It's just a regular design flaw :) If we
>> must fix it, let's do it in a way that complies with the stability
>> principle.
>> >
>> > Cheers
>> > Simon
>> >
>> >
>> > On Mon, 29 Jan 2024 at 11:15, Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>> > > Hi,
>> > >
>> > > Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:
>> > > > I might be a bit confused, but doesn't this proposal change the
>> meaning of an existing
>> > > > extension (PatternSignatures)?
>> > >
>> > > a long-ago deprecated one:
>> > >
>> > > ~ $ ghci
>> > > GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
>> > > ghci> :set -XPatternSignatures
>> > >
>> > > <no location info>: warning: [-Wdeprecated-flags]
>> > >     -XPatternSignatures is deprecated: use -XScopedTypeVariables or
>> pragma {-# LANGUAGE ScopedTypeVariables #-} instead
>> > >
>> > > Hopefully our stability principles does not require us to heed
>> programs
>> > > that ignored deprecation flags for a while?
>> > >
>> > > My understanding of
>> > >
>> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles
>> > > is that, despite “stable package” not saying “does not use features
>> > > deprecated long ago”, it’s still ok to break such programs, as this is
>> > > our mechanism GR3?
>> > >
>> > >
>> > > Of course we could side-step this procedural question about
>> repurposing
>> > > an old extension and introduce `SimplePatternSignatures` instead. Not
>> > > in favor, simply because as a user I more than once intuitively
>> reached
>> > > for `PatternSignatures` to get the proposed behavior.
>> > >
>> > > Cheers,
>> > > Joachim
>> > >
>> > >
>> > > _______________________________________________
>> > > ghc-steering-committee mailing list
>> > > ghc-steering-committee at haskell.org
>> > >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/053831b6/attachment-0001.html>

From marlowsd at gmail.com  Mon Jan 29 15:30:17 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 29 Jan 2024 15:30:17 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <CALkkMoR=aALOYAmit8t42t_duj--mW-se-qGkNb5K5zXVtRUVA@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
 <7ee154a4cc3b782b8f40cbe57b2af0f46deea85d.camel@joachim-breitner.de>
 <CANsrgPLZ8_eDPk7dHDuWNjVKiONAphJo4r0HjR9WDmOCoB9Jrw@mail.gmail.com>
 <14dbafad95a577f2f4905a6ee793b23c67bda4d2.camel@joachim-breitner.de>
 <CANsrgP+nvhWn4KPoLewWKbShiUnaUKF_2cUUDDVdwuN-ZEs-uA@mail.gmail.com>
 <CALkkMoR=aALOYAmit8t42t_duj--mW-se-qGkNb5K5zXVtRUVA@mail.gmail.com>
Message-ID: <CANsrgPKfVyzH0JyuaWwd77RKUes5p=qevGpzkUeXP7EzrPeJmQ@mail.gmail.com>

On Mon, 29 Jan 2024 at 13:56, Richard Eisenberg <reisenberg at janestreet.com>
wrote:

> Simon M:
>
> deciding that the stability principles don't apply to pre-existing
> deprecations would not be in the right spirit, if you ask me
>
>
> To me, it's in the spirit of "deprecation", if not stability. That is,
> what does it mean to deprecate a feature? I think it means that users
> should expect the feature to disappear at some point in the future; in
> other words, it explicitly labels a feature as non-stable. Up until now, we
> hadn't settled on a meaning of stability, and so by extension we hadn't
> settled on a meaning for deprecation. So maybe we say "the feature wasn't
> actually deprecated because we didn't know what *deprecated* meant", but
> I think this one has been labeled deprecated for long enough that we should
> feel comfortable removing it / changing it.
>

This raises an interesting distinction that I hadn't realised before (and
sorry about the tangent but it seemed important to highlight). We may
actually want two different kinds of deprecation:

1. Deprecated and may change in a future GHC release (GR3-style
deprecation; we expect these to be rare)
2. Deprecated and may change in a future language edition (no impact on
stability; doesn't require GR2 justification; more common)

I kind of expected most existing deprecations would turn into (2) given the
new stability requirements.

Cheers
Simon



>
> ---------------
>
> My initial support for this proposal was based on the fact that it made a
> few people happy. Now it's become clear that it also makes a few people
> unhappy. I'm still hoping for a language-edition-based future
> <https://github.com/ghc-proposals/ghc-proposals/pull/628> where this
> proposal doesn't matter, so I'm pretty agnostic. Maybe on balance it's a
> better use of time debating that potential future (I'll prepare a proper
> proposal this week) than to debate this finer point?
>
> Richard
>
> On Mon, Jan 29, 2024 at 8:07 AM Simon Marlow <marlowsd at gmail.com> wrote:
>
>> Hmm, deciding that the stability principles don't apply to pre-existing
>> deprecations would not be in the right spirit, if you ask me. I think we
>> should apply the rules consistently to every proposal going forward, being
>> already deprecated doesn't get you a pass. In this case we really don't
>> have to break existing code, so let's not do it.
>>
>> It's not that hard to make a new extension or to change the behaviour in
>> GHC2024 is it?
>>
>> Cheers
>> Simon
>>
>>
>>
>> On Mon, 29 Jan 2024 at 11:42, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>>> Hi,
>>>
>>> well, we were more liberal at deprecating things in the past than we
>>> will be under the new regime, and we might not have invoked GR2 here.
>>>
>>> But the extension already _is_ deprecated. If deprecating (even for the
>>> wrong reasons) and waiting multiple releases does not allow us to break
>>> the deprecated thing, then what is the point of GR3?
>>>
>>> I am quite fond of the new stability regime, it sets out
>>> clear requirements on code (set a language flag, heed deprecation
>>> warnings, although the latter could be spelled out more explicitly), in
>>> return for clear promises. Let’s not water this down by not taking the
>>> set of requirements of requirements seriously ourselves.
>>>
>>> Cheers,
>>> Joachim
>>>
>>> Am Montag, dem 29.01.2024 um 11:32 +0000 schrieb Simon Marlow:
>>> > "Only exceptionally would we fix a design flaw in a way that breaks
>>> programs compiled with existing language editions."
>>> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2
>>> >
>>> > This is not exceptional is it? It's just a regular design flaw :) If
>>> we must fix it, let's do it in a way that complies with the stability
>>> principle.
>>> >
>>> > Cheers
>>> > Simon
>>> >
>>> >
>>> > On Mon, 29 Jan 2024 at 11:15, Joachim Breitner <
>>> mail at joachim-breitner.de> wrote:
>>> > > Hi,
>>> > >
>>> > > Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:
>>> > > > I might be a bit confused, but doesn't this proposal change the
>>> meaning of an existing
>>> > > > extension (PatternSignatures)?
>>> > >
>>> > > a long-ago deprecated one:
>>> > >
>>> > > ~ $ ghci
>>> > > GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
>>> > > ghci> :set -XPatternSignatures
>>> > >
>>> > > <no location info>: warning: [-Wdeprecated-flags]
>>> > >     -XPatternSignatures is deprecated: use -XScopedTypeVariables or
>>> pragma {-# LANGUAGE ScopedTypeVariables #-} instead
>>> > >
>>> > > Hopefully our stability principles does not require us to heed
>>> programs
>>> > > that ignored deprecation flags for a while?
>>> > >
>>> > > My understanding of
>>> > >
>>> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles
>>> > > is that, despite “stable package” not saying “does not use features
>>> > > deprecated long ago”, it’s still ok to break such programs, as this
>>> is
>>> > > our mechanism GR3?
>>> > >
>>> > >
>>> > > Of course we could side-step this procedural question about
>>> repurposing
>>> > > an old extension and introduce `SimplePatternSignatures` instead. Not
>>> > > in favor, simply because as a user I more than once intuitively
>>> reached
>>> > > for `PatternSignatures` to get the proposed behavior.
>>> > >
>>> > > Cheers,
>>> > > Joachim
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > ghc-steering-committee mailing list
>>> > > ghc-steering-committee at haskell.org
>>> > >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/ded576ee/attachment.html>

From adam at well-typed.com  Mon Jan 29 16:34:54 2024
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 29 Jan 2024 16:34:54 +0000
Subject: [ghc-steering-committee] Please review #631: Set program exit
 code by main return type, Shepherd: Arnaud
In-Reply-To: <CAGwnsnm49Fa4mNyPHTmM36ZHx+v4oEXJYJaNHazdoDKg1e5gHw@mail.gmail.com>
References: <d89aa1d0-59ff-4a1c-b460-8bd2803fae25@well-typed.com>
 <CAGwnsnm49Fa4mNyPHTmM36ZHx+v4oEXJYJaNHazdoDKg1e5gHw@mail.gmail.com>
Message-ID: <b63ae92e-8865-4c71-acf4-962ed8233186@well-typed.com>

On 29/01/2024 09:24, Arnaud Spiwack wrote:
> I can be the shepherd, but, full disclosure: Shea is my colleague at Tweag.

Thanks for flagging this up. We should properly articulate this in the 
by-laws, but as per the precedent set by my esteemed predecessor 
(https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002948.html), 
I don't think it is necessarily a problem to shepherd proposals from 
colleagues, provided you feel you can do so objectively.

Adam


> On Sat, 27 Jan 2024 at 21:15, Adam Gundry <adam at well-typed.com 
> <mailto:adam at well-typed.com>> wrote:
> 
>     Dear Committee,
> 
>     Shea Levy proposes that the value returned by `main` should determine
>     the exit code of the program:
> 
>     https://github.com/ghc-proposals/ghc-proposals/pull/631
>     <https://github.com/ghc-proposals/ghc-proposals/pull/631>
> 
>     https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst <https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst>
> 
>     I'd like to nominate Arnaud as the shepherd.
> 
>     Please guide us to a conclusion as outlined in
>     https://github.com/ghc-proposals/ghc-proposals#committee-process
>     <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> 
>     Cheers,
> 
>     Adam


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From arnaud.spiwack at tweag.io  Tue Jan 30 06:14:39 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 30 Jan 2024 07:14:39 +0100
Subject: [ghc-steering-committee] Please review #631: Set program exit
 code by main return type, Shepherd: Arnaud
In-Reply-To: <b63ae92e-8865-4c71-acf4-962ed8233186@well-typed.com>
References: <d89aa1d0-59ff-4a1c-b460-8bd2803fae25@well-typed.com>
 <CAGwnsnm49Fa4mNyPHTmM36ZHx+v4oEXJYJaNHazdoDKg1e5gHw@mail.gmail.com>
 <b63ae92e-8865-4c71-acf4-962ed8233186@well-typed.com>
Message-ID: <CAGwnsn=r0v1=fyuZAA43AAoT4Fioy6woHmNsWHv5_dr9hxQpAQ@mail.gmail.com>

I've been a precedent on both sides too :-) . I don't think it's a problem,
but I did want to disclose that fact ahead of time.

On Mon, 29 Jan 2024 at 17:34, Adam Gundry <adam at well-typed.com> wrote:

> On 29/01/2024 09:24, Arnaud Spiwack wrote:
> > I can be the shepherd, but, full disclosure: Shea is my colleague at
> Tweag.
>
> Thanks for flagging this up. We should properly articulate this in the
> by-laws, but as per the precedent set by my esteemed predecessor
> (
> https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002948.html),
>
> I don't think it is necessarily a problem to shepherd proposals from
> colleagues, provided you feel you can do so objectively.
>
> Adam
>
>
> > On Sat, 27 Jan 2024 at 21:15, Adam Gundry <adam at well-typed.com
> > <mailto:adam at well-typed.com>> wrote:
> >
> >     Dear Committee,
> >
> >     Shea Levy proposes that the value returned by `main` should determine
> >     the exit code of the program:
> >
> >     https://github.com/ghc-proposals/ghc-proposals/pull/631
> >     <https://github.com/ghc-proposals/ghc-proposals/pull/631>
> >
> >
> https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst
> <
> https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst
> >
> >
> >     I'd like to nominate Arnaud as the shepherd.
> >
> >     Please guide us to a conclusion as outlined in
> >     https://github.com/ghc-proposals/ghc-proposals#committee-process
> >     <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> >
> >     Cheers,
> >
> >     Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
>

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240130/8f6c17c5/attachment-0001.html>

From adam at well-typed.com  Wed Jan 31 21:30:32 2024
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 31 Jan 2024 21:30:32 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <CANsrgPKfVyzH0JyuaWwd77RKUes5p=qevGpzkUeXP7EzrPeJmQ@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
 <7ee154a4cc3b782b8f40cbe57b2af0f46deea85d.camel@joachim-breitner.de>
 <CANsrgPLZ8_eDPk7dHDuWNjVKiONAphJo4r0HjR9WDmOCoB9Jrw@mail.gmail.com>
 <14dbafad95a577f2f4905a6ee793b23c67bda4d2.camel@joachim-breitner.de>
 <CANsrgP+nvhWn4KPoLewWKbShiUnaUKF_2cUUDDVdwuN-ZEs-uA@mail.gmail.com>
 <CALkkMoR=aALOYAmit8t42t_duj--mW-se-qGkNb5K5zXVtRUVA@mail.gmail.com>
 <CANsrgPKfVyzH0JyuaWwd77RKUes5p=qevGpzkUeXP7EzrPeJmQ@mail.gmail.com>
Message-ID: <ed0b6af5-58d7-44c8-b4fa-8e7004c6c2b3@well-typed.com>

John responded to some of this discussion on the proposal: 
https://github.com/ghc-proposals/ghc-proposals/pull/608#issuecomment-1919413031.

I think we should try to resolve this thread rather than leave it 
hanging. Given Simon's opposition to the idea of changing 
PatternSignatures, it seems to me the next best thing would be Joachim's 
observation that we could define a new extension SimplePatternSignatures 
(or however we call it) and modify #448 to use that instead. Perhaps 
that's a compromise we can live with? John indicates that he'd be happy 
with that outcome.

Cheers,

Adam



On 29/01/2024 15:30, Simon Marlow wrote:
> On Mon, 29 Jan 2024 at 13:56, Richard Eisenberg 
> <reisenberg at janestreet.com <mailto:reisenberg at janestreet.com>> wrote:
> 
>     Simon M:
> 
>         deciding that the stability principles don't apply to
>         pre-existing deprecations would not be in the right spirit, if
>         you ask me
> 
> 
>     To me, it's in the spirit of "deprecation", if not stability. That
>     is, what does it mean to deprecate a feature? I think it means that
>     users should expect the feature to disappear at some point in the
>     future; in other words, it explicitly labels a feature as
>     non-stable. Up until now, we hadn't settled on a meaning of
>     stability, and so by extension we hadn't settled on a meaning for
>     deprecation. So maybe we say "the feature wasn't actually deprecated
>     because we didn't know what /deprecated/ meant", but I think this
>     one has been labeled deprecated for long enough that we should feel
>     comfortable removing it / changing it.
> 
> 
> This raises an interesting distinction that I hadn't realised before 
> (and sorry about the tangent but it seemed important to highlight). We 
> may actually want two different kinds of deprecation:
> 
> 1. Deprecated and may change in a future GHC release (GR3-style 
> deprecation; we expect these to be rare)
> 2. Deprecated and may change in a future language edition (no impact on 
> stability; doesn't require GR2 justification; more common)
> 
> I kind of expected most existing deprecations would turn into (2) given 
> the new stability requirements.
> 
> Cheers
> Simon
> 
> 
>     ---------------
> 
>     My initial support for this proposal was based on the fact that it
>     made a few people happy. Now it's become clear that it also makes a
>     few people unhappy. I'm still hoping for a language-edition-based
>     future <https://github.com/ghc-proposals/ghc-proposals/pull/628>
>     where this proposal doesn't matter, so I'm pretty agnostic. Maybe on
>     balance it's a better use of time debating that potential future
>     (I'll prepare a proper proposal this week) than to debate this finer
>     point?
> 
>     Richard
> 
>     On Mon, Jan 29, 2024 at 8:07 AM Simon Marlow <marlowsd at gmail.com
>     <mailto:marlowsd at gmail.com>> wrote:
> 
>         Hmm, deciding that the stability principles don't apply to
>         pre-existing deprecations would not be in the right spirit, if
>         you ask me. I think we should apply the rules consistently to
>         every proposal going forward, being already deprecated doesn't
>         get you a pass. In this case we really don't have to break
>         existing code, so let's not do it.
> 
>         It's not that hard to make a new extension or to change the
>         behaviour in GHC2024 is it?
> 
>         Cheers
>         Simon
> 
> 
> 
>         On Mon, 29 Jan 2024 at 11:42, Joachim Breitner
>         <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> 
>             Hi,
> 
>             well, we were more liberal at deprecating things in the past
>             than we
>             will be under the new regime, and we might not have invoked
>             GR2 here.
> 
>             But the extension already _is_ deprecated. If deprecating
>             (even for the
>             wrong reasons) and waiting multiple releases does not allow
>             us to break
>             the deprecated thing, then what is the point of GR3?
> 
>             I am quite fond of the new stability regime, it sets out
>             clear requirements on code (set a language flag, heed
>             deprecation
>             warnings, although the latter could be spelled out more
>             explicitly), in
>             return for clear promises. Let’s not water this down by not
>             taking the
>             set of requirements of requirements seriously ourselves.
> 
>             Cheers,
>             Joachim
> 
>             Am Montag, dem 29.01.2024 um 11:32 +0000 schrieb Simon Marlow:
>              > "Only exceptionally would we fix a design flaw in a way
>             that breaks programs compiled with existing language
>             editions."
>             https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2 <https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2>
>              >
>              > This is not exceptional is it? It's just a regular design
>             flaw :) If we must fix it, let's do it in a way that
>             complies with the stability principle.
>              >
>              > Cheers
>              > Simon
>              >
>              >
>              > On Mon, 29 Jan 2024 at 11:15, Joachim Breitner
>             <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
>             wrote:
>              > > Hi,
>              > >
>              > > Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon
>             Marlow:
>              > > > I might be a bit confused, but doesn't this proposal
>             change the meaning of an existing
>              > > > extension (PatternSignatures)?
>              > >
>              > > a long-ago deprecated one:
>              > >
>              > > ~ $ ghci
>              > > GHCi, version 9.4.8: https://www.haskell.org/ghc/
>             <https://www.haskell.org/ghc/>  :? for help
>              > > ghci> :set -XPatternSignatures
>              > >
>              > > <no location info>: warning: [-Wdeprecated-flags]
>              > >     -XPatternSignatures is deprecated: use
>             -XScopedTypeVariables or pragma {-# LANGUAGE
>             ScopedTypeVariables #-} instead
>              > >
>              > > Hopefully our stability principles does not require us
>             to heed programs
>              > > that ignored deprecation flags for a while?
>              > >
>              > > My understanding of
>              > >
>             https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles <https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles>
>              > > is that, despite “stable package” not saying “does not
>             use features
>              > > deprecated long ago”, it’s still ok to break such
>             programs, as this is
>              > > our mechanism GR3?
>              > >
>              > >
>              > > Of course we could side-step this procedural question
>             about repurposing
>              > > an old extension and introduce
>             `SimplePatternSignatures` instead. Not
>              > > in favor, simply because as a user I more than once
>             intuitively reached
>              > > for `PatternSignatures` to get the proposed behavior.
>              > >
>              > > Cheers,
>              > > Joachim


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

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England