From mail at joachim-breitner.de  Tue Feb  2 08:04:17 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 02 Feb 2021 09:04:17 +0100
Subject: [ghc-steering-committee] Voting on the Simons
In-Reply-To: <3b3347b13dc485cb4a61500720a440a82a64b4fe.camel@joachim-breitner.de>
References: <b4f5e13cebd0f6d9775d8563540d30dc0d00ad52.camel@joachim-breitner.de>
 <CANsrgPKubfWFdb_yORMtnVkyk6i6jtqD0YehZVMtZgSHX_G4VA@mail.gmail.com>
 <3b3347b13dc485cb4a61500720a440a82a64b4fe.camel@joachim-breitner.de>
Message-ID: <9e73b88c5b8b1d3ae7643b425b8fae88cc6fca66.camel@joachim-breitner.de>

Hi everyone,

I have received enough votes to determine a majority (I was about to
complain that I am one vote short and would have nudged you all … but
then I remembered that I don't typically send emails to myself.)

With 6 yay and 0 nay each, at a committee size of 11, I can happily and
unexpectedly announce that both Simons are confirmed for another term
of 3 years.

BTW, we _still_ need someone to play secretary and run the next round
of nominations and voting.

Cheers,
Joachim


Am Dienstag, den 26.01.2021, 10:55 +0100 schrieb Joachim Breitner:
> Hi
> 
> > > Simons:
> > > Do you want to stay on the committee?
> 
> Am Freitag, den 22.01.2021, 14:50 +0000 schrieb Simon Peyton Jones:
> > Yes, I am willing
> 
> Am Dienstag, den 26.01.2021, 09:35 +0000 schrieb Simon Marlow:
> > Yes please, if you'll still have me :)
> 
> Thanks! The bylaws indicate
> 
> > If either wishes to continue serving on the committee when their
> > 
> terms end, and if the majority of the rest of the committee supports
> > this outcome, no public nomination process needs to take place to
> > replace them.
> 
> It doesn’t say whether the vote is public or private,
> but it is customary to hold votes about people in private. In
> particular, the person voted on should not see the votes.
> 
> Therefore I invite everyone to send their vote to me by direct mail.
> Please indicate for both Simons whether you support them continuing.
> Sim
> ons: I guess you get to vote on each other.
> 
> Once I have enough votes to determine the outcome, I will announce it
> here (anonymously, i.e. just he tally).
> 
> I also assume that “rest of the committee” includes the expiring
> members, because why not.
> 
> The bylaws are not fully clear on whether this vote extends their term
> just until the next nomination round, or by another three years. But if
> one understands this as a short-cut through the full re-nomination
> process, then I conclude it means a new three year term starts for
> them.
> 
> (Is this process a bit silly? But I guess a bit of ceremony is good.)
> 
> 
> BTW, still looking for a volunteer to run the main nomination process.
> 
> 
> Cheers,
> Joachim
> 
> 
> 
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From tomjharding at live.co.uk  Tue Feb  2 10:24:05 2021
From: tomjharding at live.co.uk (Tom Harding)
Date: Tue, 2 Feb 2021 10:24:05 +0000
Subject: [ghc-steering-committee] Committee review #368: Warn on
 prefix/suffix operators
In-Reply-To: <CAHnFXOu_YVYxxyQREt0NaXN5=22K9BsLkV383=aCpXgvEC4vRw@mail.gmail.com>
References: <1de9b874ff276009c7e95c86dd732ecd8cfc446f.camel@joachim-breitner.de>
 <DC6B3956-5E5B-4BC2-ABB6-EDAE6B3AE72D@live.co.uk>
 <CAHnFXOu_YVYxxyQREt0NaXN5=22K9BsLkV383=aCpXgvEC4vRw@mail.gmail.com>
Message-ID: <018C77B7-A022-4E77-9EF9-43EA162BC5EF@live.co.uk>

Hi Joachim,

After two weeks and no thumbs down, I think we should mark this one as accepted!

Thanks,
Tom

On 18 Jan 2021, at 21:03, Alejandro Serrano Mena <trupill at gmail.com<mailto:trupill at gmail.com>> wrote:

Looks sensible to me.

Alejandro

On 15 Jan 2021 at 16:09:59, Tom Harding <tomjharding at live.co.uk<mailto:tomjharding at live.co.uk>> wrote:
Hi all,

Richard has proposed a small change to the previously accepted “Whitespace-sensitive operator parsing” proposal (whose current state is rendered here<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst>), specifically to say that the described warning be triggered by -Wall and -Wcompat.
I think this is sensible and hopefully not particularly controversial, and I recommend that we accept.

The updated proposal may be viewed here<https://github.com/goldfirere/ghc-proposals/blob/88690a542ada41dccd0f58d252ed6d392140034d/proposals/0000-prefix-suffix-operators.rst#proposed-change-specification>; please reply with any thoughts/concerns!

Thanks,
Tom

On 9 Jan 2021, at 16:43, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:

Dear Committee,

this is your secretary speaking:

Warn on prefix/suffix operators
has been proposed by Richard
https://github.com/ghc-proposals/ghc-proposals/pull/368

This is an amendment to #229 (Whitespace-sensitive operator parsing),
see the PR description linked above for details.

I’ll propose Tom as the shepherd.

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

Thanks,
Joachim
--
Joachim Breitner
 mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
 http://www.joachim-breitner.de/


_______________________________________________
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

_______________________________________________
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

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

From mail at joachim-breitner.de  Tue Feb  2 10:37:30 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 02 Feb 2021 11:37:30 +0100
Subject: [ghc-steering-committee] Committee review #368: Warn on
 prefix/suffix operators
In-Reply-To: <018C77B7-A022-4E77-9EF9-43EA162BC5EF@live.co.uk>
References: <1de9b874ff276009c7e95c86dd732ecd8cfc446f.camel@joachim-breitner.de>
 <DC6B3956-5E5B-4BC2-ABB6-EDAE6B3AE72D@live.co.uk>
 <CAHnFXOu_YVYxxyQREt0NaXN5=22K9BsLkV383=aCpXgvEC4vRw@mail.gmail.com>
 <018C77B7-A022-4E77-9EF9-43EA162BC5EF@live.co.uk>
Message-ID: <4a7ce6e6805ea1c38afb7996c618c8be4b454ceb.camel@joachim-breitner.de>

Thanks, merged.

Am Dienstag, den 02.02.2021, 10:24 +0000 schrieb Tom Harding:
> Hi Joachim,
> 
> After two weeks and no thumbs down, I think we should mark this one as accepted!
> 
> Thanks,
> Tom
> 
> > On 18 Jan 2021, at 21:03, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> > 
> > Looks sensible to me.
> > 
> > Alejandro
> > 
> > On 15 Jan 2021 at 16:09:59, Tom Harding <tomjharding at live.co.uk> wrote:
> > > Hi all,
> > > 
> > > Richard has proposed a small change to the previously accepted “Whitespace-sensitive operator parsing” proposal (whose current state is rendered here), specifically to say that the described warning be triggered by -Wall and -Wcompat.
> > > I think this is sensible and hopefully not particularly controversial, and I recommend that we accept.
> > > 
> > > The updated proposal may be viewed here; please reply with any thoughts/concerns!
> > > 
> > > Thanks,
> > > Tom
> > > 
> > > > On 9 Jan 2021, at 16:43, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > > > 
> > > > Dear Committee,
> > > > 
> > > > this is your secretary speaking:
> > > > 
> > > > Warn on prefix/suffix operators
> > > > has been proposed by Richard
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/368
> > > > 
> > > > This is an amendment to #229 (Whitespace-sensitive operator parsing),
> > > > see the PR description linked above for details.
> > > > 
> > > > I’ll propose Tom as the shepherd.
> > > > 
> > > > Please guide us to a conclusion as outlined in 
> > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > > 
> > > > Thanks,
> > > > 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
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Sat Feb  6 15:42:24 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 06 Feb 2021 16:42:24 +0100
Subject: [ghc-steering-committee] Upcoming call for nominations
In-Reply-To: <9e73b88c5b8b1d3ae7643b425b8fae88cc6fca66.camel@joachim-breitner.de>
References: <b4f5e13cebd0f6d9775d8563540d30dc0d00ad52.camel@joachim-breitner.de>
 <CANsrgPKubfWFdb_yORMtnVkyk6i6jtqD0YehZVMtZgSHX_G4VA@mail.gmail.com>
 <3b3347b13dc485cb4a61500720a440a82a64b4fe.camel@joachim-breitner.de>
 <9e73b88c5b8b1d3ae7643b425b8fae88cc6fca66.camel@joachim-breitner.de>
Message-ID: <16e5c38a5fbec444276c94ebd894dc757c5a2fbd.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 02.02.2021, 09:04 +0100 schrieb Joachim Breitner:
> BTW, we _still_ need someone to play secretary and run the next round
> of nominations and voting.

I guess this is the stereotypical call for volunteers that echoes
silently in the big hall.

Let me make an arbitrary concrete suggestion, and ask Alejandro: Would
you be willing to jump in and pull this through?

Steps are
 * send out the call for nomiations
 * collect the nominations
 * send them in private mail to all _active_ members
 * collect the votes
 * announce the result

Of course I’ll assist and advice.

Cheers,
Joachim

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



From trupill at gmail.com  Mon Feb  8 07:49:59 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Mon, 8 Feb 2021 07:49:59 +0000
Subject: [ghc-steering-committee] Upcoming call for nominations
In-Reply-To: <16e5c38a5fbec444276c94ebd894dc757c5a2fbd.camel@joachim-breitner.de>
References: <b4f5e13cebd0f6d9775d8563540d30dc0d00ad52.camel@joachim-breitner.de>
 <CANsrgPKubfWFdb_yORMtnVkyk6i6jtqD0YehZVMtZgSHX_G4VA@mail.gmail.com>
 <3b3347b13dc485cb4a61500720a440a82a64b4fe.camel@joachim-breitner.de>
 <9e73b88c5b8b1d3ae7643b425b8fae88cc6fca66.camel@joachim-breitner.de>
 <16e5c38a5fbec444276c94ebd894dc757c5a2fbd.camel@joachim-breitner.de>
Message-ID: <CAHnFXOvHOTZ5+O_s9QeC1Tb7NMGPwD-Q11zTG5Epfq8PhgnY_g@mail.gmail.com>

 Hi,
Yes, I am willing to do this. I’ll look for the previous call for
nominations and send it around (I guess mailing lists, Reddit, Twitter,
Discourse are the places to be).

Regards,
Alejandro

On 6 Feb 2021 at 16:42:24, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Dienstag, den 02.02.2021, 09:04 +0100 schrieb Joachim Breitner:
>
> BTW, we _still_ need someone to play secretary and run the next round
>
> of nominations and voting.
>
>
> I guess this is the stereotypical call for volunteers that echoes
> silently in the big hall.
>
> Let me make an arbitrary concrete suggestion, and ask Alejandro: Would
> you be willing to jump in and pull this through?
>
> Steps are
> * send out the call for nomiations
> * collect the nominations
> * send them in private mail to all _active_ members
> * collect the votes
> * announce the result
>
> Of course I’ll assist and advice.
>
> 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/20210208/65f29a82/attachment.html>

From mail at joachim-breitner.de  Mon Feb  8 07:59:52 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 08 Feb 2021 08:59:52 +0100
Subject: [ghc-steering-committee] Upcoming call for nominations
In-Reply-To: <CAHnFXOvHOTZ5+O_s9QeC1Tb7NMGPwD-Q11zTG5Epfq8PhgnY_g@mail.gmail.com>
References: <b4f5e13cebd0f6d9775d8563540d30dc0d00ad52.camel@joachim-breitner.de>
 <CANsrgPKubfWFdb_yORMtnVkyk6i6jtqD0YehZVMtZgSHX_G4VA@mail.gmail.com>
 <3b3347b13dc485cb4a61500720a440a82a64b4fe.camel@joachim-breitner.de>
 <9e73b88c5b8b1d3ae7643b425b8fae88cc6fca66.camel@joachim-breitner.de>
 <16e5c38a5fbec444276c94ebd894dc757c5a2fbd.camel@joachim-breitner.de>
 <CAHnFXOvHOTZ5+O_s9QeC1Tb7NMGPwD-Q11zTG5Epfq8PhgnY_g@mail.gmail.com>
Message-ID: <9a559c8daf40efeabb679825e02a4de91f922ba7.camel@joachim-breitner.de>

Hi,

thanks!

I sent it to haskell-cafe@ and haskell@ (note that I think you have to
subscribe first to haskell@). I didn't think of Discourse, so it’s good
that someone else does it for a change :-)

Cheers,
Joachim

Am Montag, den 08.02.2021, 07:49 +0000 schrieb Alejandro Serrano Mena:
> Yes, I am willing to do this. I’ll look for the previous call for nominations and send it around (I guess mailing lists, Reddit, Twitter, Discourse are the places to be).
> 
> Regards,
> Alejandro
> 
> On 6 Feb 2021 at 16:42:24, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > Hi,
> > 
> > Am Dienstag, den 02.02.2021, 09:04 +0100 schrieb Joachim Breitner:
> > > BTW, we _still_ need someone to play secretary and run the next round
> > > of nominations and voting.
> > 
> > I guess this is the stereotypical call for volunteers that echoes
> > silently in the big hall.
> > 
> > Let me make an arbitrary concrete suggestion, and ask Alejandro: Would
> > you be willing to jump in and pull this through?
> > 
> > Steps are
> > * send out the call for nomiations
> > * collect the nominations
> > * send them in private mail to all _active_ members
> > * collect the votes
> > * announce the result
> > 
> > Of course I’ll assist and advice.
> > 
> > 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 mail at joachim-breitner.de  Tue Feb  9 15:07:29 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 09 Feb 2021 16:07:29 +0100
Subject: [ghc-steering-committee] Please review #390: Fine-grained pragmas,
 Shepherd: Vitaly
Message-ID: <8078b270df4cd622b67b9b49e4ab8a0ed38b7156.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Fine-grained pragmas for classes, families, and instances
has been proposed by Alejandro
https://github.com/ghc-proposals/ghc-proposals/pull/390
https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md
I’ll propose Vitaly Bragilevsky as the shepherd.

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

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



From bravit111 at gmail.com  Tue Feb  9 15:16:47 2021
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Tue, 9 Feb 2021 18:16:47 +0300
Subject: [ghc-steering-committee] Please review #390: Fine-grained
 pragmas, Shepherd: Vitaly
In-Reply-To: <8078b270df4cd622b67b9b49e4ab8a0ed38b7156.camel@joachim-breitner.de>
References: <8078b270df4cd622b67b9b49e4ab8a0ed38b7156.camel@joachim-breitner.de>
Message-ID: <CALpVSmMuW1h7KJ8XVXrAA0Ho9-QFjdNS-zVYGwbE=74OQ27DpA@mail.gmail.com>

Will do, thanks!

Vitaly

вт, 9 февр. 2021 г., 18:07 Joachim Breitner <mail at joachim-breitner.de>:

> Dear Committee,
>
> this is your secretary speaking:
>
> Fine-grained pragmas for classes, families, and instances
> has been proposed by Alejandro
> https://github.com/ghc-proposals/ghc-proposals/pull/390
>
> https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md
> I’ll propose Vitaly Bragilevsky as the shepherd.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Thanks,
> 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/20210209/640ef2cf/attachment.html>

From trupill at gmail.com  Sat Feb 13 20:20:40 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Sat, 13 Feb 2021 20:20:40 +0000
Subject: [ghc-steering-committee] Request for Nominations to the GHC
	Steering Committee
Message-ID: <CAHnFXOsdqHee8PwAwb+kuRgc42BUOC+=K+6BhnpWKPG5hSS88Q@mail.gmail.com>

Dear Haskell community,

The three-year term limit of some of the GHC Steering committee
members has expired. We are really grateful for the awesome work
that Iavor, Richard, and Joachim have done through these years
(especially the latter, who has acted as secretary.) As a result, the
GHC Steering committee is seeking nominations for new members.

The committee scrutinizes, nitpicks, improves, weights and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC.
Our processes are described at
   https://github.com/ghc-proposals/ghc-proposals
which is also the GitHub repository where proposals are proposed.

We are looking for members who have the ability
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and
   specifications,
 * comment constructively and improve the proposals,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

We look for committee members who have some of these properties:
 * have substantial experience in writing Haskell applications or
   libraries, which they can use to inform judgements about the
   utility or otherwise of proposed features,
 * have made active contributions to the Haskell community, for
   some time,
 * have expertise in language design and implementation, in either
   Haskell or related languages, which they can share with us.

The committee’s work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. We
estimate the workload to be around 2 hours per week, and our process
works best if members usually respond to technical emails within 1-2
weeks (within days is even better). Please keep that in mind if your
email inbox is already overflowing.

The GHC developers themselves are already well represented already.  We
seek Haskell _users_ more than GHC hackers.

There is no shortage of people who are eager to get fancy new
features into the language, both in the committee and the wider
community. But each new feature imposes a cost, to implement, to learn,
(particularly) through its unexpected interaction with other features.
We need to strike a balance, one that encourages innovation (as GHC
always has) while still making Haskell attractive for real-world
production use and for teaching. We therefore explicitly invite
“conservative” members of the community to join the committee.

To make a nomination, please send an email to me (as the interim committee
secretary) at trupill at gmail.com until February 28th. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

We explicitly encourage self-nominations. You can nominate others, but
please obtain their explicit consent to do so. (We don’t want to choose
someone who turns out to be unable to serve.)

On behalf of the committee,
Alejandro Serrano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210213/b44cb1ca/attachment.html>

From mail at joachim-breitner.de  Thu Feb 18 10:32:13 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 18 Feb 2021 11:32:13 +0100
Subject: [ghc-steering-committee]  Status
Message-ID: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>

Dear Committee,

another status update, because why not.

A small reminder: These mails have two sections, one that’s a delta
since last status, but below is a summary of all proposals we have to
act on. Please at least scroll through that on each status mail to see
if you are listed, maybe you forgot something (or I made a mistake).

So here’s the delta since last month.

 * GHC2021 defined! Yay!

 * Bylaws merged! Yay

 * Simon², Iavor, Richard and me had thus their terms expired.

   The Simons, as key members, wanted to continue and were
   voted back in.

   The others are now “expiring”, until the next nomination round
   concludes. Alejandro is going to run that process.

 * we were asked to review these proposals:
   #390: Fine-grained pragmas, Shepherd: Vitaly

 * we have a recommendation from the shepherd about:
   #368: Warn on prefix/suffix operators (accept)

 * we have sent the following proposals back to revision
   - none -

 * we decided about the following proposals
   #313: Delimited continuation primops (accept)
   #387: The Char kind (accept)
   #368: Warn on prefix/suffix operators (accept)

We currently have to act on the following 5 proposals, down by 2.

## Waiting for committee decision

#381: Visible 'forall' in types of terms, Shepherd: Iavor
      Recommendation was to reject, but discussion went into the more 
      abstract “whither dependent Haskell”. But what does this mean
      for this proposal?
      Iavor, can you pick this up again?

#369: Add sumToTag# primop, Shepherd: Eric
      Essentially accepted, waiting for feedback from the author on
      final tweaks. Eric, care to nudge the author, or just do it?

#302: \of, Shepherd: Cale
      No new discussion yet. It seems there was some confusion, which
      was cleared up by Tom, and Cale said he’ll pick it up now again.


## Waiting for Shepherd action

#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
      Simon said he’d reject it on the Github PR. Still waiting
      for the discussion to start on the mailing list.

#390: Fine-grained pragmas, Shepherd: Vitaly
      Still kinda new, but a recommendation would be good soon.


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



From eric at seidel.io  Thu Feb 18 14:49:10 2021
From: eric at seidel.io (Eric Seidel)
Date: Thu, 18 Feb 2021 09:49:10 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Please_review_=23369=3A_Add_su?=
 =?utf-8?q?mToTag=23_primop=2C_Shepherd=3A_Eric?=
In-Reply-To: <010f0175748d93a9-ce8da12a-83f0-48a1-8eab-201acc6a85cd-000000@us-east-2.amazonses.com>
References: <aeb980341be95777caa9a689f32b3d186b9870fa.camel@joachim-breitner.de>
 <d48f3d1a-f802-42bf-87cd-f22d3e6a1116@www.fastmail.com>
 <CAH6fHQn_y5=y6irfv+mD+zVS8tcNrnWMe2Z7RvSZ53LQi45EhA@mail.gmail.com>
 <CAHnFXOv+k+M33=mR7d7XrteSfo2h00ek-Vu8aPurD2wjYsWaAA@mail.gmail.com>
 <010f0175748d93a9-ce8da12a-83f0-48a1-8eab-201acc6a85cd-000000@us-east-2.amazonses.com>
Message-ID: <99028d96-07e8-4b19-a66f-bcb726cd506f@www.fastmail.com>

Hi all,

This proposal has been lingering for a while in an all-but-accepted state (thanks Joachim for the nudge!). We had a couple of suggestions to improve the wording of the specification that the author has not responded to. Since they don't affect the content of the proposed change, I suggest we just merge the PR with the suggested improvements.

Eric

On Thu, Oct 29, 2020, at 09:30, Richard Eisenberg wrote:
> Yes, I support this.
> 
> Richard
> 
> > On Oct 28, 2020, at 5:08 PM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> > 
> > I am also fine with the proposal.
> > 
> > Alejandro
> > 
> > El mié., 28 oct. 2020 a las 16:13, Spiwack, Arnaud (<arnaud.spiwack at tweag.io>) escribió:
> >> The wording of the specification section is still a bit awkward, in my opinion. Other than that, I'm fine with the proposal.
> >> 
> >> On Wed, Oct 28, 2020 at 12:52 AM Eric Seidel <eric at seidel.io> wrote:
> >>> Hi all,
> >>> 
> >>> I have recommended acceptance of this proposal. It's a simple addition that fills what appears to be a gap in our API around unboxed sums (we already provide `dataToTag#` for lifted types).
> >>> 
> >>> Please take a look.
> >>> 
> >>> https://github.com/ghc-proposals/ghc-proposals/pull/369
> >>> 
> >>> Thanks!
> >>> Eric
> >>> 
> >>> On Thu, Oct 22, 2020, at 03:31, Joachim Breitner wrote:
> >>> > Dear Committee,
> >>> > 
> >>> > this is your secretary speaking:
> >>> > 
> >>> > Add sumToTag# primop
> >>> > has been proposed by David Feuer
> >>> > https://github.com/ghc-proposals/ghc-proposals/pull/369
> >>> > https://github.com/treeowl/ghc-proposals/blob/sum-to-tag/proposals/0000-sum-to-tag.md
> >>> > 
> >>> > I’ll propose Eric Seidel as the shepherd.
> >>> > 
> >>> > Please guide us to a conclusion as outlined in 
> >>> > https://github.com/ghc-proposals/ghc-proposals#committee-process
> >>> > 
> >>> > Thanks,
> >>> > 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
> > _______________________________________________
> > 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 iavor.diatchki at gmail.com  Thu Feb 18 16:47:22 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 18 Feb 2021 08:47:22 -0800
Subject: [ghc-steering-committee] Status
In-Reply-To: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
Message-ID: <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>

On #381 I think the idea of visible quantification makes sense every now
and then, but I don't like the concrete details of the proposal: the magic
lifting of terms to types seems quite complicated, and using `type` as an
explicit herald doesn't look nice.  So I don't think it's the right design,
and therefore I suggest we reject the proposal.

I am sure that others would disagree as apparently this is an essential
part of dependent Haskell.   I have not followed the large discussion that
Richard created, as I am not particularly interested in the design being
proposed, so perhaps someone else should champion this.

Aslo, I am not sure if I am actually on the committee, as I thought my term
had expired?  That might be more reason for someone else to pick it up.

-Iavor



On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> another status update, because why not.
>
> A small reminder: These mails have two sections, one that’s a delta
> since last status, but below is a summary of all proposals we have to
> act on. Please at least scroll through that on each status mail to see
> if you are listed, maybe you forgot something (or I made a mistake).
>
> So here’s the delta since last month.
>
>  * GHC2021 defined! Yay!
>
>  * Bylaws merged! Yay
>
>  * Simon², Iavor, Richard and me had thus their terms expired.
>
>    The Simons, as key members, wanted to continue and were
>    voted back in.
>
>    The others are now “expiring”, until the next nomination round
>    concludes. Alejandro is going to run that process.
>
>  * we were asked to review these proposals:
>    #390: Fine-grained pragmas, Shepherd: Vitaly
>
>  * we have a recommendation from the shepherd about:
>    #368: Warn on prefix/suffix operators (accept)
>
>  * we have sent the following proposals back to revision
>    - none -
>
>  * we decided about the following proposals
>    #313: Delimited continuation primops (accept)
>    #387: The Char kind (accept)
>    #368: Warn on prefix/suffix operators (accept)
>
> We currently have to act on the following 5 proposals, down by 2.
>
> ## Waiting for committee decision
>
> #381: Visible 'forall' in types of terms, Shepherd: Iavor
>       Recommendation was to reject, but discussion went into the more
>       abstract “whither dependent Haskell”. But what does this mean
>       for this proposal?
>       Iavor, can you pick this up again?
>
> #369: Add sumToTag# primop, Shepherd: Eric
>       Essentially accepted, waiting for feedback from the author on
>       final tweaks. Eric, care to nudge the author, or just do it?
>
> #302: \of, Shepherd: Cale
>       No new discussion yet. It seems there was some confusion, which
>       was cleared up by Tom, and Cale said he’ll pick it up now again.
>
>
> ## Waiting for Shepherd action
>
> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>       Simon said he’d reject it on the Github PR. Still waiting
>       for the discussion to start on the mailing list.
>
> #390: Fine-grained pragmas, Shepherd: Vitaly
>       Still kinda new, but a recommendation would be good soon.
>
>
> 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/20210218/8c0272b1/attachment.html>

From mail at joachim-breitner.de  Thu Feb 18 17:08:47 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 18 Feb 2021 18:08:47 +0100
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
Message-ID: <6dfc3d69abfb11d4d56e6681e3f0a8d0e7dbe8aa.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 18.02.2021, 08:47 -0800 schrieb Iavor Diatchki:
> Aslo, I am not sure if I am actually on the committee, as I thought
> my term had expired?  That might be more reason for someone else to
> pick it up.

expiring members stay active until the end of the nomination process,
so that an expiring member who wants to stay on and re-nominates
themselves can thus serve uninterrupted.

I sincerely hope that you will want to stay on, Iavor, and send a
nomination to Alejandro. It would be a pity to lose one of our most
active, most reliable and longest serving member because of some
procedural fluff that we added with good intentions.

Cheers,
Joachim


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



From mail at joachim-breitner.de  Thu Feb 18 17:10:44 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 18 Feb 2021 18:10:44 +0100
Subject: [ghc-steering-committee] Please review #369: Add sumToTag#
 primop, Shepherd: Eric
In-Reply-To: <99028d96-07e8-4b19-a66f-bcb726cd506f@www.fastmail.com>
References: <aeb980341be95777caa9a689f32b3d186b9870fa.camel@joachim-breitner.de>
 <d48f3d1a-f802-42bf-87cd-f22d3e6a1116@www.fastmail.com>
 <CAH6fHQn_y5=y6irfv+mD+zVS8tcNrnWMe2Z7RvSZ53LQi45EhA@mail.gmail.com>
 <CAHnFXOv+k+M33=mR7d7XrteSfo2h00ek-Vu8aPurD2wjYsWaAA@mail.gmail.com>
 <010f0175748d93a9-ce8da12a-83f0-48a1-8eab-201acc6a85cd-000000@us-east-2.amazonses.com>
 <99028d96-07e8-4b19-a66f-bcb726cd506f@www.fastmail.com>
Message-ID: <b9f4f78b76ffa867985b1c6701878f3b968eb9f6.camel@joachim-breitner.de>

Hi Eric,

that’s reasonable. I don’t think the authors “own” the PR in a strong
sense, and fixes that come out of the committee deliberations can be
applied before merging without their final approval. It’s still nice to
wait and see if they like it, but not for too long. Unless they
unticked a box, you should be able to commit to their branch.

Let me know when the PR is ready!

Cheers,
Joachim


Am Donnerstag, den 18.02.2021, 09:49 -0500 schrieb Eric Seidel:
> Hi all,
> 
> This proposal has been lingering for a while in an all-but-accepted state (thanks Joachim for the nudge!). We had a couple of suggestions to improve the wording of the specification that the author has not responded to. Since they don't affect the content of the proposed change, I suggest we just merge the PR with the suggested improvements.
> 
> Eric
> 
> On Thu, Oct 29, 2020, at 09:30, Richard Eisenberg wrote:
> > Yes, I support this.
> > 
> > Richard
> > 
> > > On Oct 28, 2020, at 5:08 PM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> > > 
> > > I am also fine with the proposal.
> > > 
> > > Alejandro
> > > 
> > > El mié., 28 oct. 2020 a las 16:13, Spiwack, Arnaud (<arnaud.spiwack at tweag.io>) escribió:
> > > > The wording of the specification section is still a bit awkward, in my opinion. Other than that, I'm fine with the proposal.
> > > > 
> > > > On Wed, Oct 28, 2020 at 12:52 AM Eric Seidel <eric at seidel.io> wrote:
> > > > > Hi all,
> > > > > 
> > > > > I have recommended acceptance of this proposal. It's a simple addition that fills what appears to be a gap in our API around unboxed sums (we already provide `dataToTag#` for lifted types).
> > > > > 
> > > > > Please take a look.
> > > > > 
> > > > > https://github.com/ghc-proposals/ghc-proposals/pull/369
> > > > > 
> > > > > Thanks!
> > > > > Eric
> > > > > 
> > > > > On Thu, Oct 22, 2020, at 03:31, Joachim Breitner wrote:
> > > > > > Dear Committee,
> > > > > > 
> > > > > > this is your secretary speaking:
> > > > > > 
> > > > > > Add sumToTag# primop
> > > > > > has been proposed by David Feuer
> > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/369
> > > > > > https://github.com/treeowl/ghc-proposals/blob/sum-to-tag/proposals/0000-sum-to-tag.md
> > > > > > 
> > > > > > I’ll propose Eric Seidel as the shepherd.
> > > > > > 
> > > > > > Please guide us to a conclusion as outlined in 
> > > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > > > > 
> > > > > > Thanks,
> > > > > > 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
> > > _______________________________________________
> > > 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 eric at seidel.io  Thu Feb 18 17:53:34 2021
From: eric at seidel.io (Eric Seidel)
Date: Thu, 18 Feb 2021 12:53:34 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Please_review_=23369=3A_Add_su?=
 =?utf-8?q?mToTag=23_primop=2C_Shepherd=3A_Eric?=
In-Reply-To: <b9f4f78b76ffa867985b1c6701878f3b968eb9f6.camel@joachim-breitner.de>
References: <aeb980341be95777caa9a689f32b3d186b9870fa.camel@joachim-breitner.de>
 <d48f3d1a-f802-42bf-87cd-f22d3e6a1116@www.fastmail.com>
 <CAH6fHQn_y5=y6irfv+mD+zVS8tcNrnWMe2Z7RvSZ53LQi45EhA@mail.gmail.com>
 <CAHnFXOv+k+M33=mR7d7XrteSfo2h00ek-Vu8aPurD2wjYsWaAA@mail.gmail.com>
 <010f0175748d93a9-ce8da12a-83f0-48a1-8eab-201acc6a85cd-000000@us-east-2.amazonses.com>
 <99028d96-07e8-4b19-a66f-bcb726cd506f@www.fastmail.com>
 <b9f4f78b76ffa867985b1c6701878f3b968eb9f6.camel@joachim-breitner.de>
Message-ID: <2bfe9bdd-20dd-4213-9ff2-7d10aaf26df3@www.fastmail.com>

I applied the changes we suggested and David approved, let's merge!

On Thu, Feb 18, 2021, at 12:10, Joachim Breitner wrote:
> Hi Eric,
> 
> that’s reasonable. I don’t think the authors “own” the PR in a strong
> sense, and fixes that come out of the committee deliberations can be
> applied before merging without their final approval. It’s still nice to
> wait and see if they like it, but not for too long. Unless they
> unticked a box, you should be able to commit to their branch.
> 
> Let me know when the PR is ready!
> 
> Cheers,
> Joachim
> 
> 
> Am Donnerstag, den 18.02.2021, 09:49 -0500 schrieb Eric Seidel:
> > Hi all,
> > 
> > This proposal has been lingering for a while in an all-but-accepted state (thanks Joachim for the nudge!). We had a couple of suggestions to improve the wording of the specification that the author has not responded to. Since they don't affect the content of the proposed change, I suggest we just merge the PR with the suggested improvements.
> > 
> > Eric
> > 
> > On Thu, Oct 29, 2020, at 09:30, Richard Eisenberg wrote:
> > > Yes, I support this.
> > > 
> > > Richard
> > > 
> > > > On Oct 28, 2020, at 5:08 PM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> > > > 
> > > > I am also fine with the proposal.
> > > > 
> > > > Alejandro
> > > > 
> > > > El mié., 28 oct. 2020 a las 16:13, Spiwack, Arnaud (<arnaud.spiwack at tweag.io>) escribió:
> > > > > The wording of the specification section is still a bit awkward, in my opinion. Other than that, I'm fine with the proposal.
> > > > > 
> > > > > On Wed, Oct 28, 2020 at 12:52 AM Eric Seidel <eric at seidel.io> wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > I have recommended acceptance of this proposal. It's a simple addition that fills what appears to be a gap in our API around unboxed sums (we already provide `dataToTag#` for lifted types).
> > > > > > 
> > > > > > Please take a look.
> > > > > > 
> > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/369
> > > > > > 
> > > > > > Thanks!
> > > > > > Eric
> > > > > > 
> > > > > > On Thu, Oct 22, 2020, at 03:31, Joachim Breitner wrote:
> > > > > > > Dear Committee,
> > > > > > > 
> > > > > > > this is your secretary speaking:
> > > > > > > 
> > > > > > > Add sumToTag# primop
> > > > > > > has been proposed by David Feuer
> > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/369
> > > > > > > https://github.com/treeowl/ghc-proposals/blob/sum-to-tag/proposals/0000-sum-to-tag.md
> > > > > > > 
> > > > > > > I’ll propose Eric Seidel as the shepherd.
> > > > > > > 
> > > > > > > Please guide us to a conclusion as outlined in 
> > > > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > 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
> > > > _______________________________________________
> > > > 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/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From mail at joachim-breitner.de  Thu Feb 18 21:21:16 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 18 Feb 2021 22:21:16 +0100
Subject: [ghc-steering-committee] Please review #369: Add sumToTag#
 primop, Shepherd: Eric
In-Reply-To: <2bfe9bdd-20dd-4213-9ff2-7d10aaf26df3@www.fastmail.com>
References: <aeb980341be95777caa9a689f32b3d186b9870fa.camel@joachim-breitner.de>
 <d48f3d1a-f802-42bf-87cd-f22d3e6a1116@www.fastmail.com>
 <CAH6fHQn_y5=y6irfv+mD+zVS8tcNrnWMe2Z7RvSZ53LQi45EhA@mail.gmail.com>
 <CAHnFXOv+k+M33=mR7d7XrteSfo2h00ek-Vu8aPurD2wjYsWaAA@mail.gmail.com>
 <010f0175748d93a9-ce8da12a-83f0-48a1-8eab-201acc6a85cd-000000@us-east-2.amazonses.com>
 <99028d96-07e8-4b19-a66f-bcb726cd506f@www.fastmail.com>
 <b9f4f78b76ffa867985b1c6701878f3b968eb9f6.camel@joachim-breitner.de>
 <2bfe9bdd-20dd-4213-9ff2-7d10aaf26df3@www.fastmail.com>
Message-ID: <ef10475ff03e22a57f5b9a6344ff2e89c7e3b41f.camel@joachim-breitner.de>

Am Donnerstag, den 18.02.2021, 12:53 -0500 schrieb Eric Seidel:
> I applied the changes we suggested and David approved, let's merge!

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



From simonpj at microsoft.com  Thu Feb 18 21:54:22 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 18 Feb 2021 21:54:22 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
Message-ID: <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>

There has been a broad further discussion.
What we advertise is that, rather that leave a proposal "under committee review", we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion.  That's different to reject... it means that there is an ongoing debate so it's not a good time for the committee to make a decision.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 18 February 2021 16:47
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Status

On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice.  So I don't think it's the right design, and therefore I suggest we reject the proposal.

I am sure that others would disagree as apparently this is an essential part of dependent Haskell.   I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this.

Aslo, I am not sure if I am actually on the committee, as I thought my term had expired?  That might be more reason for someone else to pick it up.

-Iavor



On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

another status update, because why not.

A small reminder: These mails have two sections, one that's a delta
since last status, but below is a summary of all proposals we have to
act on. Please at least scroll through that on each status mail to see
if you are listed, maybe you forgot something (or I made a mistake).

So here's the delta since last month.

 * GHC2021 defined! Yay!

 * Bylaws merged! Yay

 * Simon², Iavor, Richard and me had thus their terms expired.

   The Simons, as key members, wanted to continue and were
   voted back in.

   The others are now "expiring", until the next nomination round
   concludes. Alejandro is going to run that process.

 * we were asked to review these proposals:
   #390: Fine-grained pragmas, Shepherd: Vitaly

 * we have a recommendation from the shepherd about:
   #368: Warn on prefix/suffix operators (accept)

 * we have sent the following proposals back to revision
   - none -

 * we decided about the following proposals
   #313: Delimited continuation primops (accept)
   #387: The Char kind (accept)
   #368: Warn on prefix/suffix operators (accept)

We currently have to act on the following 5 proposals, down by 2.

## Waiting for committee decision

#381: Visible 'forall' in types of terms, Shepherd: Iavor
      Recommendation was to reject, but discussion went into the more
      abstract "whither dependent Haskell". But what does this mean
      for this proposal?
      Iavor, can you pick this up again?

#369: Add sumToTag# primop, Shepherd: Eric
      Essentially accepted, waiting for feedback from the author on
      final tweaks. Eric, care to nudge the author, or just do it?

#302: \of, Shepherd: Cale
      No new discussion yet. It seems there was some confusion, which
      was cleared up by Tom, and Cale said he'll pick it up now again.


## Waiting for Shepherd action

#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
      Simon said he'd reject it on the Github PR. Still waiting
      for the discussion to start on the mailing list.

#390: Fine-grained pragmas, Shepherd: Vitaly
      Still kinda new, but a recommendation would be good soon.


Cheers,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cbc1da190b85a4cf21e4b08d8d42ceb8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637492636704547033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=5wTbz6wc4abeqyC3TXDU2O8kftB9Rwz1dHnkXM%2FGErE%3D&reserved=0>


_______________________________________________
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cbc1da190b85a4cf21e4b08d8d42ceb8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637492636704557030%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0MJhOYvjonZABu01LyVUN2zqOKC3xqf5qEidT8d%2B2os%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210218/130feab2/attachment-0001.html>

From bravit111 at gmail.com  Sat Feb 20 11:34:12 2021
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Sat, 20 Feb 2021 14:34:12 +0300
Subject: [ghc-steering-committee] #390: Fine-grained pragmas,
	recommendation: accept
Message-ID: <CALpVSmPJDcaPaWNUKrE4gUOatQ0gLj=RQaxi5Ew+R3bxm_P_ww@mail.gmail.com>

Dear Committee,

Our own Alejandro has been proposed
Fine-grained pragmas for classes, families, and instances
https://github.com/ghc-proposals/ghc-proposals/pull/390
https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md

His idea is to bring the flexibility of overlaps/overlapping/overlappable
pragmas to termination checking, type inference, and constraint solving.
Alejandro proposes to introduce the following %-modifiers (as in already
accepted #370,
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-modifiers.rst
):
%NoTerminationCheck
%LiberalCoverage
%LiberalInjectivity
%Overlapping
%Overlappable
%Overlaps
to liberate conditions for classes and instances, type families,
forall-types, etc. The first three modifiers can be used instead of the
scary-sounding UndecidableInstances extension. The last three modifiers are
supposed to be used instead of the  overlap*-pragmas for instances we
already have. Note that this proposal doesn't suggest deprecating those
extensions and pragmas.

I think that this proposal goes in the right direction and recommend
accepting it.

As far as I understand, all the committee members, including those with
terms about to expire, have the right to either support this proposal or to
raise a voice against it either here or at
https://github.com/ghc-proposals/ghc-proposals/pull/390.

Regards,
Vitaly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210220/b87a7e2f/attachment.html>

From mail at joachim-breitner.de  Sat Feb 20 11:44:09 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 20 Feb 2021 12:44:09 +0100
Subject: [ghc-steering-committee] Please review #405: Split RecordDotSyntax,
	Shepherd: Simon PJ
Message-ID: <79e64e0ed2c7f0f7a6dab6a3943a4d36ee9c54be.camel@joachim-breitner.de>

Dear Committe,

Split RecordDotSyntax into two extensions
has been proposed by Shayne Fletcher
https://github.com/ghc-proposals/ghc-proposals/pull/405

This is an amendment to #282, proposing to introduce
separate extensions OverloadedRecordDot and OverloadedRecordUpdate
instead.

I’ll propose Simon PJ as the shepherd, given that he has shepherded
#282.

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

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



From mail at joachim-breitner.de  Sat Feb 20 11:46:36 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 20 Feb 2021 12:46:36 +0100
Subject: [ghc-steering-committee] Please review #403: lexical structure of
 numbers and identifiers, Shepherd: Arnaud
Message-ID: <702aad6cb77225471cb7ea89cd5a9e4d13cd5658.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Cleanup lexical structure of numbers and identifiers
has been proposed by Oleg Grenus
https://github.com/ghc-proposals/ghc-proposals/pull/403
https://github.com/phadej/ghc-proposals/blob/cleanup-lexical-structure/proposals/0000-cleanup-lexical-structure.md

I propose Arnaud as the shepherd.

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

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



From mail at joachim-breitner.de  Mon Feb 22 11:30:39 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 22 Feb 2021 12:30:39 +0100
Subject: [ghc-steering-committee] Please review #400: Constrained COMPLETE
 sets, Shepherd: Cale
Message-ID: <e2d6e356378b1d920f4277c633aaf65fdbe9d287.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Constrained COMPLETE sets
has been proposed by Sebastian Graph
https://github.com/ghc-proposals/ghc-proposals/pull/400
https://github.com/sgraf812/ghc-proposals/blob/constrained-complete-sigs/proposals/0000-constrained-complete-sets.rst


This proposal tries to solve the same issue as Cale’s #399, and
essentially has slightly different syntax. I therefore suggest that
Cale is the shepherd, and hashes out with Sebastian the details of
syntax so that they can both get behind it, and then makes a
recommendation.

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

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



From simonpj at microsoft.com  Tue Feb 23 15:06:02 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 23 Feb 2021 15:06:02 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax propsal
Message-ID: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Friends
Please see this proposal #405 to split RecordDotSyntax into two extensions<https://github.com/ghc-proposals/ghc-proposals/pull/405>
It is a small modification of #282 on record dot syntax.   The top comment gives links to the versions of the proposal before and after the change.
The main payload is:

  *   Instead of RecordDotSyntax, have to independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.

I recommend acceptance of this proposal, but invite the committee's view on one point (the final bullet below). Here is the thinking

  *   RecordDotSyntax is the extension that we will eventually want programmers to user. It will probably ultimately imply NoFieldSelectors. But we aren't quite ready make that choice yet. So we don't want to specify exactly what RecordDotSyntax does yet.
  *   So we want another, less ambitious, extension to enable record-dot syntax itself, and its desugaring into getField; and similarly for record updates.
  *   This patch to the proposal goes just a little further, by dis-aggregating into two independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.
  *   An alternative, if the committee prefers, would be to have a single extension (say, OverloadedRecords).
Please express your opinion.  This should not take us long.   (Technical and clarification questions would be best done on the Githhub thread, as always.)
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210223/46b3f7bc/attachment.html>

From mail at joachim-breitner.de  Tue Feb 23 16:35:59 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 23 Feb 2021 17:35:59 +0100
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <def3efbf5dbbf6c6cd109a9b2484a4ad6571fc27.camel@joachim-breitner.de>

Hi,

fine with acceptance. Having more fine grained extensions while we are
not 100% where the thing is going may pay off in the future, while
GHC2028 (rough guess) or Haskell2030 (who knows?) will alleviate the
pain of too fine-grained extensions.

Cheers,
Joachim

Am Dienstag, den 23.02.2021, 15:06 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> Friends
> Please see this proposal #405 to split RecordDotSyntax into two extensions
> It is a small modification of #282 on record dot syntax.   The top comment gives links to the versions of the proposal before and after the change.
> The main payload is:
> Instead of RecordDotSyntax, have to independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.
> I recommend acceptance of this proposal, but invite the committee’s view on one point (the final bullet below). Here is the thinking
> RecordDotSyntax is the extension that we will eventually want programmers to user. It will probably ultimately imply NoFieldSelectors. But we aren’t quite ready make that choice yet. So we don’t want to specify exactly what RecordDotSyntax does yet.
> So we want another, less ambitious, extension to enable record-dot syntax itself, and its desugaring into getField; and similarly for record updates.
> This patch to the proposal goes just a little further, by dis-aggregating into two independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.
> An alternative, if the committee prefers, would be to have a single extension (say, OverloadedRecords).
> Please express your opinion.  This should not take us long.   (Technical and clarification questions would be best done on the Githhub thread, as always.)
> Simon
> _______________________________________________
> 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 mail at joachim-breitner.de  Tue Feb 23 18:23:37 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 23 Feb 2021 19:23:37 +0100
Subject: [ghc-steering-committee] Please review #402: Stable GADT
 constructor syntax, Shepherd: Richard
Message-ID: <01d4bac39d051cd2bbef7d9c2f71f6eb20f794b2.camel@joachim-breitner.de>

Dear Committe,

Stable GADT constructor syntax
has been proposed by Vladislav Zavialov
https://github.com/ghc-proposals/ghc-proposals/pull/402
https://github.com/serokell/ghc-proposals/blob/gadt-syntax/proposals/0000-gadt-syntax.rst

I propose Richard as the shepherd.

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

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



From rae at richarde.dev  Tue Feb 23 21:12:39 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 23 Feb 2021 21:12:39 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <def3efbf5dbbf6c6cd109a9b2484a4ad6571fc27.camel@joachim-breitner.de>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <def3efbf5dbbf6c6cd109a9b2484a4ad6571fc27.camel@joachim-breitner.de>
Message-ID: <010f0177d0bca471-030c3a87-7747-4c66-b849-23a6ac62dd99-000000@us-east-2.amazonses.com>

I've posted on GitHub (https://github.com/ghc-proposals/ghc-proposals/pull/405#issuecomment-784515926 <https://github.com/ghc-proposals/ghc-proposals/pull/405#issuecomment-784515926>). I'm unconvinced by this motivation, unfortunately.

Richard

> On Feb 23, 2021, at 11:35 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> fine with acceptance. Having more fine grained extensions while we are
> not 100% where the thing is going may pay off in the future, while
> GHC2028 (rough guess) or Haskell2030 (who knows?) will alleviate the
> pain of too fine-grained extensions.
> 
> Cheers,
> Joachim
> 
> Am Dienstag, den 23.02.2021, 15:06 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
>> Friends
>> Please see this proposal #405 to split RecordDotSyntax into two extensions
>> It is a small modification of #282 on record dot syntax.   The top comment gives links to the versions of the proposal before and after the change.
>> The main payload is:
>> Instead of RecordDotSyntax, have to independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.
>> I recommend acceptance of this proposal, but invite the committee’s view on one point (the final bullet below). Here is the thinking
>> RecordDotSyntax is the extension that we will eventually want programmers to user. It will probably ultimately imply NoFieldSelectors. But we aren’t quite ready make that choice yet. So we don’t want to specify exactly what RecordDotSyntax does yet.
>> So we want another, less ambitious, extension to enable record-dot syntax itself, and its desugaring into getField; and similarly for record updates.
>> This patch to the proposal goes just a little further, by dis-aggregating into two independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.
>> An alternative, if the committee prefers, would be to have a single extension (say, OverloadedRecords).
>> Please express your opinion.  This should not take us long.   (Technical and clarification questions would be best done on the Githhub thread, as always.)
>> Simon
>> _______________________________________________
>> 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/20210223/94643943/attachment-0001.html>

From simonpj at microsoft.com  Fri Feb 26 09:32:38 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 26 Feb 2021 09:32:38 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Friends
There has been a bit of discussion, but it seems to have died down again.  Any other views?
Richard, you were a bit negative - has the intervening discussion reassured you?
I'd like us to decide pretty soon.... no point in delay.
Simon
From: Simon Peyton Jones <simonpj at microsoft.com>
Sent: 23 February 2021 15:06
To: ghc-steering-committee <ghc-steering-committee at haskell.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com>
Subject: Modification to record dot syntax propsal

Friends
Please see this proposal #405 to split RecordDotSyntax into two extensions<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F405&data=04%7C01%7Csimonpj%40microsoft.com%7Caa27192c62ab448a4e2c08d8d80c8937%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637496895641978235%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oJDy%2BiYI4kEaC%2FUJIfZbph2JnZr%2FTK%2F5aZqA6djwF3A%3D&reserved=0>
It is a small modification of #282 on record dot syntax.   The top comment gives links to the versions of the proposal before and after the change.
The main payload is:

  *   Instead of RecordDotSyntax, have to independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.

I recommend acceptance of this proposal, but invite the committee's view on one point (the final bullet below). Here is the thinking

  *   RecordDotSyntax is the extension that we will eventually want programmers to user. It will probably ultimately imply NoFieldSelectors. But we aren't quite ready make that choice yet. So we don't want to specify exactly what RecordDotSyntax does yet.
  *   So we want another, less ambitious, extension to enable record-dot syntax itself, and its desugaring into getField; and similarly for record updates.
  *   This patch to the proposal goes just a little further, by dis-aggregating into two independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.
  *   An alternative, if the committee prefers, would be to have a single extension (say, OverloadedRecords).
Please express your opinion.  This should not take us long.   (Technical and clarification questions would be best done on the Githhub thread, as always.)
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210226/9fa81704/attachment.html>

From rae at richarde.dev  Fri Feb 26 15:37:41 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 26 Feb 2021 15:37:41 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>



> On Feb 26, 2021, at 4:32 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> Friends
> 
> There has been a bit of discussion, but it seems to have died down again.  Any other views?
> 
> Richard, you were a bit negative – has the intervening discussion reassured you?
> 

I was negative on the motivation, but not the proposal. I'm a bit skeptical of the end goal of a -XRecordDotSyntax that implies a bunch of other flags, but that's not on the table at the moment. I'm in support of the extension breakdown as proposed and vote to accept.

Richard

> I’d like us to decide pretty soon…. no point in delay.
> 
> Simon
> 
> From: Simon Peyton Jones <simonpj at microsoft.com> 
> Sent: 23 February 2021 15:06
> To: ghc-steering-committee <ghc-steering-committee at haskell.org>
> Cc: Simon Peyton Jones <simonpj at microsoft.com>
> Subject: Modification to record dot syntax propsal
>  
> 
> Friends
> 
> Please see this proposal #405 to split RecordDotSyntax into two extensions <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F405&data=04%7C01%7Csimonpj%40microsoft.com%7Caa27192c62ab448a4e2c08d8d80c8937%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637496895641978235%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oJDy%2BiYI4kEaC%2FUJIfZbph2JnZr%2FTK%2F5aZqA6djwF3A%3D&reserved=0>
> It is a small modification of #282 on record dot syntax.   The top comment gives links to the versions of the proposal before and after the change.
> 
> The main payload is:
> 
> Instead of RecordDotSyntax, have to independent extensions, OverloadedRecordDot and OverloadedRecordUpdates.
> I recommend acceptance of this proposal, but invite the committee’s view on one point (the final bullet below). Here is the thinking
> 
> RecordDotSyntax is the extension that we will eventually want programmers to user. It will probably ultimately implyNoFieldSelectors. But we aren’t quite ready make that choice yet. So we don’t want to specify exactly whatRecordDotSyntax does yet.
> So we want another, less ambitious, extension to enable record-dot syntax itself, and its desugaring into getField; and similarly for record updates.
> This patch to the proposal goes just a little further, by dis-aggregating into two independent extensions,OverloadedRecordDot and OverloadedRecordUpdates.
> An alternative, if the committee prefers, would be to have a single extension (say, OverloadedRecords).
> Please express your opinion.  This should not take us long.   (Technical and clarification questions would be best done on the Githhub thread, as always.)
> 
> 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/20210226/7a1c2b7e/attachment.html>

From iavor.diatchki at gmail.com  Fri Feb 26 16:19:31 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 26 Feb 2021 08:19:31 -0800
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>

I do think that  reusing the record update syntax for the overloaded
monomorphic update is a mistake---it is not something I had noticed during
our original discussion.
-Iavor

On Fri, Feb 26, 2021 at 7:37 AM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Feb 26, 2021, at 4:32 AM, Simon Peyton Jones via ghc-steering-committee
> <ghc-steering-committee at haskell.org> wrote:
>
> Friends
>
> There has been a bit of discussion, but it seems to have died down again.
> Any other views?
>
> Richard, you were a bit negative – has the intervening discussion
> reassured you?
>
>
> I was negative on the motivation, but not the proposal. I'm a bit
> skeptical of the end goal of a -XRecordDotSyntax that implies a bunch of
> other flags, but that's not on the table at the moment. I'm in support of
> the extension breakdown as proposed and vote to accept.
>
> Richard
>
> I’d like us to decide pretty soon…. no point in delay.
>
> Simon
> *From:* Simon Peyton Jones <simonpj at microsoft.com>
> *Sent:* 23 February 2021 15:06
> *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* Modification to record dot syntax propsal
>
>
>
> Friends
>
> Please see this proposal #405 to split RecordDotSyntax into two extensions
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F405&data=04%7C01%7Csimonpj%40microsoft.com%7Caa27192c62ab448a4e2c08d8d80c8937%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637496895641978235%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oJDy%2BiYI4kEaC%2FUJIfZbph2JnZr%2FTK%2F5aZqA6djwF3A%3D&reserved=0>
>
> It is a small modification of #282 on record dot syntax.   The top comment
> gives links to the versions of the proposal before and after the change.
>
> The main payload is:
>
>    - Instead of RecordDotSyntax, have to independent extensions,
>    OverloadedRecordDot and OverloadedRecordUpdates.
>
> I recommend acceptance of this proposal, but invite the committee’s view
> on one point (the final bullet below). Here is the thinking
>
>    - RecordDotSyntax is the extension that we will eventually want
>    programmers to user. It will probably ultimately implyNoFieldSelectors.
>    But we aren’t quite ready make that choice yet. So we don’t want to specify
>    exactly whatRecordDotSyntax does yet.
>    - So we want another, less ambitious, extension to enable record-dot
>    syntax itself, and its desugaring into getField; and similarly for
>    record updates.
>    - This patch to the proposal goes just a little further, by
>    dis-aggregating into two independent extensions,OverloadedRecordDot and
>     OverloadedRecordUpdates.
>    - An alternative, if the committee prefers, would be to have a single
>    extension (say, OverloadedRecords).
>
> Please express your opinion.  This should not take us long.   (Technical
> and clarification questions would be best done on the Githhub thread, as
> always.)
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210226/7c4c8fc2/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Feb 26 22:33:25 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 26 Feb 2021 23:33:25 +0100
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
Message-ID: <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>

> I do think that  reusing the record update syntax for the overloaded
> monomorphic update is a mistake---it is not something I had noticed during
> our original discussion.
>

This is the one reason I can see for cutting this extension in smaller
pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like
extension.

Generally, I'm not in favour in proposals which split extensions though: we
already have so many extensions. Are the reasons for this split strong
enough? I haven't had time to dig into the details.

I'm not sure that not having the design of the proposal quite finalised is
a good reason, extensions mutate in their first iterations, I don't think
that it's a problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210226/d603792a/attachment.html>

From simonpj at microsoft.com  Fri Feb 26 23:39:22 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 26 Feb 2021 23:39:22 +0000
Subject: [ghc-steering-committee] Modification to record dot
	syntax	propsal
In-Reply-To: <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
Message-ID: <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.

There seem to be two motivations.


  1.  There really are two orthogonal extensions, one for r.x notation, and one for overloaded update.  Iavor likes the first but not the second.  Neil likes both.  Having separate extensions lets us experiment.



  1.  You suggest that changing the definition of RecordDotSyntax in a subsequent release, e.g. by subsequently making it imply NoFieldSelectors, would be fine. But it certainly imposes pain – some programs would stop compiling.  The approach offered by this proposal avoids that problem.

Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards.  It may not be pretty to divide things up so fine, but it’s not new.


If there are alternative suggestions, let’s hear them.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
Sent: 26 February 2021 22:33
To: Iavor Diatchki <iavor.diatchki at gmail.com>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal


I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.

This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.

Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.

I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210226/df2111f6/attachment-0001.html>