From moritz.angermann at gmail.com  Sun Dec  3 00:47:17 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 3 Dec 2023 08:47:17 +0800
Subject: [ghc-steering-committee] #493: SPECIALISE with expressions,
	rec: accept
In-Reply-To: <CAHZ0NLoskD4dkRy9ZBLNT5JfgW_suWtY3EtuuStro=nTrxAcmg@mail.gmail.com>
References: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com>
 <CAHZ0NLoskD4dkRy9ZBLNT5JfgW_suWtY3EtuuStro=nTrxAcmg@mail.gmail.com>
Message-ID: <CAKfdd-wkL0ODDiEEk=-+n0NSvxu--Sj89bUuawW_FO-VHKLeaQ@mail.gmail.com>

I'm supportive of this, if it doesn't break existing code (e.g. it supports
existing code for at least a migration period,
where it warns and gives concrete guidance on how to change the code).

On Thu, 30 Nov 2023 at 20:15, Vladislav Zavialov <vlad.z.4096 at gmail.com>
wrote:

> Great idea. I've worked on some code that uses SPECIALIZE pragmas with
> large type signatures, and it would become considerably more elegant if it
> could use type applications instead.
>
> Vlad
>
> On Wed, Nov 29, 2023 at 9:25 AM 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
>>
> _______________________________________________
> 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/20231203/8cf81ae7/attachment.html>

From simon.peytonjones at gmail.com  Mon Dec  4 12:40:42 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 4 Dec 2023 12:40:42 +0000
Subject: [ghc-steering-committee] GHC2024 committee deliberation
In-Reply-To: <76dc28bb599e5c137b52b1994abcac49370849bd.camel@joachim-breitner.de>
References: <c160634c9b3293f74013c7a5f1263b9b3b972a34.camel@joachim-breitner.de>
 <dceef34525aac1bafeb890c63dba7c01a6f32b00.camel@joachim-breitner.de>
 <7902ee9068fdce04a3f872c908f69d9bb9375cc0.camel@joachim-breitner.de>
 <76dc28bb599e5c137b52b1994abcac49370849bd.camel@joachim-breitner.de>
Message-ID: <CAJKmMz-A=Lzz9pwJ3apzS=ZGhzn2b39DFz82f=V_dzhDc3D56g@mail.gmail.com>

>
> So where do we stand?
>


   - I'm happy for us to define GHC2024 now.

   - I do not feel strongly about the exact list of extensions... for me
   this is very user-driven.

   - The votes were interesting.  I would also love to see stats on
   extension usage, derived from trawling Hackage. I'm sure this has been
   done, probably many times.  Do we have data?

   - Several features were suggested that got more votes than the ones
   currently in the GHC2024 proposal. Why exclude them from our committee
   voting?    E.g. RecordWildCards seems popular.

   - Some extensions come down to taste.  Personally I don't like
   `BlockaArguments` but clearly quite a lot of people do.  So I don't really
   object.

   - Other extensions are "big": MonoLocalBinds and TypeFamilies in
   particular.   I'm OK with including them>


   - I would argue (mildly) against DefaultSignatures. It's a mature and
   stable extension, but a pretty tricky, speicalised and ad-hoc one. Data
   from usage in Hackage might affect my opinion!

Simon




On Thu, 30 Nov 2023 at 18:30, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi all,
>
> Am Mittwoch, dem 22.11.2023 um 22:11 +0100 schrieb Joachim Breitner:
> > Am Mittwoch, dem 22.11.2023 um 21:25 +0100 schrieb Joachim Breitner:
> > > I guess I could at least do a simple poll on discourse with the
> > > currently proposed extensions.
> >
> > Now at https://discourse.haskell.org/t/ghc2024-community-input/8168.
> > Not perfect (e.g. number of options on Discourse are limited), but it’s
> > something.
>
> after a week, we got 137 people to vote. This is of course not
> representative of our full target audience, but still useful input. For
> example, I didn’t expect LambdaCase to be that popular (84%). Other
> interesting bits:
>
>  * DerivingVia is the most popular extension that we do _not_ have
>    on the ballot for 2024, with 62%.
>    I think it's reasonable, I woudn’t mind maturing it a for another
>    edition cycle or so; there was talk about improving error messages.
>
>  * Lots of discussion about BlockArguments, but mostly along the lines
>    of “I use it (in Haskell or other languages), it’s great” vs.
>    “It don’t use it, it looks weird to me.”. My hypothesis is that
>    it is no harder to get used to than application-by-juxtaposition
>    or $ or other keywords, so I’m still in favor.
>
> Anyways, have a look if you are curious, and take it into account in
> your voting if I want.
>
>
> So where do we stand? Does everyone in the committee have the
> information they need to cast a vote? Should we just go ahead with
> voting, or would some committee members maybe share an assessment of
> the currently proposed extensions at
>
> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst
> to help people decide?
>
> 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/20231204/bdad8325/attachment.html>

From mail at joachim-breitner.de  Mon Dec  4 13:24:18 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 04 Dec 2023 14:24:18 +0100
Subject: [ghc-steering-committee] GHC2024 committee deliberation
In-Reply-To: <CAJKmMz-A=Lzz9pwJ3apzS=ZGhzn2b39DFz82f=V_dzhDc3D56g@mail.gmail.com>
References: <c160634c9b3293f74013c7a5f1263b9b3b972a34.camel@joachim-breitner.de>
 <dceef34525aac1bafeb890c63dba7c01a6f32b00.camel@joachim-breitner.de>
 <7902ee9068fdce04a3f872c908f69d9bb9375cc0.camel@joachim-breitner.de>
 <76dc28bb599e5c137b52b1994abcac49370849bd.camel@joachim-breitner.de>
 <CAJKmMz-A=Lzz9pwJ3apzS=ZGhzn2b39DFz82f=V_dzhDc3D56g@mail.gmail.com>
Message-ID: <c00d39ef58139ff321abb29de84ca821eae1fdb2.camel@joachim-breitner.de>

Hi,

Am Montag, dem 04.12.2023 um 12:40 +0000 schrieb Simon Peyton Jones:
> 
>  * I'm happy for us to define GHC2024 now.

Yay :-)

>  * The votes were interesting.  I would also love to see stats on
> extension usage, derived from trawling Hackage. I'm sure this has
> been done, probably many times.  Do we have data?

Not at the moment. Any volunteers to gather them?

 
>  * Several features were suggested that got more votes than the ones
> currently in the GHC2024 proposal. Why exclude them from our
> committee voting?    E.g. RecordWildCards seems popular.

Nobody actively nominated them as part of
https://github.com/ghc-proposals/ghc-proposals/pull/613

I guess you get different result is you ask in what place “please
actively nominate what you want to see” and in another, more crowded
place “here is a long list of option, just tick what you like”.

In the concrete case of RecordWildCards there are also strongly held
believes against it (it violates the LSP). Maybe that’s why nobody
nominated it.

(I personally like to use it occasionally, but that’s the reason why
_I_ wouldn’t push for it.)


Cheers,
Joachim


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


From mail at joachim-breitner.de  Mon Dec  4 13:26:08 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 04 Dec 2023 14:26:08 +0100
Subject: [ghc-steering-committee] GHC2024 committee deliberation
In-Reply-To: <c00d39ef58139ff321abb29de84ca821eae1fdb2.camel@joachim-breitner.de>
References: <c160634c9b3293f74013c7a5f1263b9b3b972a34.camel@joachim-breitner.de>
 <dceef34525aac1bafeb890c63dba7c01a6f32b00.camel@joachim-breitner.de>
 <7902ee9068fdce04a3f872c908f69d9bb9375cc0.camel@joachim-breitner.de>
 <76dc28bb599e5c137b52b1994abcac49370849bd.camel@joachim-breitner.de>
 <CAJKmMz-A=Lzz9pwJ3apzS=ZGhzn2b39DFz82f=V_dzhDc3D56g@mail.gmail.com>
 <c00d39ef58139ff321abb29de84ca821eae1fdb2.camel@joachim-breitner.de>
Message-ID: <a9f47dc174747a7a6fda817bc4d845e12f6ae80b.camel@joachim-breitner.de>

Hi,

Am Montag, dem 04.12.2023 um 14:24 +0100 schrieb Joachim Breitner:
> In the concrete case of RecordWildCards there are also strongly held
> believes against it (it violates the LSP). Maybe that’s why nobody
> nominated it.

or maybe not, it doesn't really need the type system, does it? But very
close in spirit – you cannot determine the binding structure from just
looking at a single module.

Cheers,
Joachim

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


From arnaud.spiwack at tweag.io  Mon Dec  4 14:57:48 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 4 Dec 2023 15:57:48 +0100
Subject: [ghc-steering-committee] GHC2024 committee deliberation
In-Reply-To: <a9f47dc174747a7a6fda817bc4d845e12f6ae80b.camel@joachim-breitner.de>
References: <c160634c9b3293f74013c7a5f1263b9b3b972a34.camel@joachim-breitner.de>
 <dceef34525aac1bafeb890c63dba7c01a6f32b00.camel@joachim-breitner.de>
 <7902ee9068fdce04a3f872c908f69d9bb9375cc0.camel@joachim-breitner.de>
 <76dc28bb599e5c137b52b1994abcac49370849bd.camel@joachim-breitner.de>
 <CAJKmMz-A=Lzz9pwJ3apzS=ZGhzn2b39DFz82f=V_dzhDc3D56g@mail.gmail.com>
 <c00d39ef58139ff321abb29de84ca821eae1fdb2.camel@joachim-breitner.de>
 <a9f47dc174747a7a6fda817bc4d845e12f6ae80b.camel@joachim-breitner.de>
Message-ID: <CAGwnsnkWkrxOoeDvULngkaSi358TGw3cr6HcBgTFd4hsNbVdsg@mail.gmail.com>

On this topic, I really like NamedFieldPuns, what do we think about it? I
sometimes feel I'm the only person in the world using them (borrowing from
Ocaml where they're pretty common). But, on the other hand, I really like
them.

On Mon, 4 Dec 2023 at 14:26, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, dem 04.12.2023 um 14:24 +0100 schrieb Joachim Breitner:
> > In the concrete case of RecordWildCards there are also strongly held
> > believes against it (it violates the LSP). Maybe that’s why nobody
> > nominated it.
>
> or maybe not, it doesn't really need the type system, does it? But very
> close in spirit – you cannot determine the binding structure from just
> looking at a single module.
>
> 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
>


-- 
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/20231204/69d90aed/attachment.html>

From mail at joachim-breitner.de  Mon Dec  4 15:30:22 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 04 Dec 2023 16:30:22 +0100
Subject: [ghc-steering-committee] GHC2024 committee deliberation
In-Reply-To: <CAGwnsnkWkrxOoeDvULngkaSi358TGw3cr6HcBgTFd4hsNbVdsg@mail.gmail.com>
References: <c160634c9b3293f74013c7a5f1263b9b3b972a34.camel@joachim-breitner.de>
 <dceef34525aac1bafeb890c63dba7c01a6f32b00.camel@joachim-breitner.de>
 <7902ee9068fdce04a3f872c908f69d9bb9375cc0.camel@joachim-breitner.de>
 <76dc28bb599e5c137b52b1994abcac49370849bd.camel@joachim-breitner.de>
 <CAJKmMz-A=Lzz9pwJ3apzS=ZGhzn2b39DFz82f=V_dzhDc3D56g@mail.gmail.com>
 <c00d39ef58139ff321abb29de84ca821eae1fdb2.camel@joachim-breitner.de>
 <a9f47dc174747a7a6fda817bc4d845e12f6ae80b.camel@joachim-breitner.de>
 <CAGwnsnkWkrxOoeDvULngkaSi358TGw3cr6HcBgTFd4hsNbVdsg@mail.gmail.com>
Message-ID: <e834e663dc06dfc2bd4f411edeb151b02eb0f80a.camel@joachim-breitner.de>

Hi,


Am Montag, dem 04.12.2023 um 15:57 +0100 schrieb Arnaud Spiwack:
> On this topic, I really like NamedFieldPuns, what do we think about
> it? I sometimes feel I'm the only person in the world using them
> (borrowing from Ocaml where they're pretty common). But, on the other
> hand, I really like them.

same here. My impression is that they have become common place in a few
languages now, and there is no reason not to have them in Haskell as
well.

THB, if this was a pubquiz I’d have lost a point by guessing that it’s
already part of GHC2021.

Ah, no, I do win the points: They are in GHC2021 according to
https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/control.html#extension-GHC2021

Cheers,
Joachim

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


From arnaud.spiwack at tweag.io  Mon Dec  4 15:40:23 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 4 Dec 2023 16:40:23 +0100
Subject: [ghc-steering-committee] GHC2024 committee deliberation
In-Reply-To: <e834e663dc06dfc2bd4f411edeb151b02eb0f80a.camel@joachim-breitner.de>
References: <c160634c9b3293f74013c7a5f1263b9b3b972a34.camel@joachim-breitner.de>
 <dceef34525aac1bafeb890c63dba7c01a6f32b00.camel@joachim-breitner.de>
 <7902ee9068fdce04a3f872c908f69d9bb9375cc0.camel@joachim-breitner.de>
 <76dc28bb599e5c137b52b1994abcac49370849bd.camel@joachim-breitner.de>
 <CAJKmMz-A=Lzz9pwJ3apzS=ZGhzn2b39DFz82f=V_dzhDc3D56g@mail.gmail.com>
 <c00d39ef58139ff321abb29de84ca821eae1fdb2.camel@joachim-breitner.de>
 <a9f47dc174747a7a6fda817bc4d845e12f6ae80b.camel@joachim-breitner.de>
 <CAGwnsnkWkrxOoeDvULngkaSi358TGw3cr6HcBgTFd4hsNbVdsg@mail.gmail.com>
 <e834e663dc06dfc2bd4f411edeb151b02eb0f80a.camel@joachim-breitner.de>
Message-ID: <CAGwnsnmB3efo3NBWSDxbfTrsowSO=m5NG5P8_eBo_XHa7SLNCg@mail.gmail.com>

Good. You win the pub quiz, I lose. But it's the sweetest kind of defeat.

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

> Hi,
>
>
> Am Montag, dem 04.12.2023 um 15:57 +0100 schrieb Arnaud Spiwack:
> > On this topic, I really like NamedFieldPuns, what do we think about
> > it? I sometimes feel I'm the only person in the world using them
> > (borrowing from Ocaml where they're pretty common). But, on the other
> > hand, I really like them.
>
> same here. My impression is that they have become common place in a few
> languages now, and there is no reason not to have them in Haskell as
> well.
>
> THB, if this was a pubquiz I’d have lost a point by guessing that it’s
> already part of GHC2021.
>
> Ah, no, I do win the points: They are in GHC2021 according to
>
> https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/control.html#extension-GHC2021
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>

-- 
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/20231204/930fa8a4/attachment.html>

From mail at joachim-breitner.de  Thu Dec  7 10:19:56 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 07 Dec 2023 11:19:56 +0100
Subject: [ghc-steering-committee]  Please review #624: Linear lets,
 Shepherd: Richard
Message-ID: <6535df22c99fc905589633fe815197ae0d3f97ae.camel@joachim-breitner.de>

Dear Committee,

Arnaud wants to amend linear types with linear lets:
https://github.com/ghc-proposals/ghc-proposals/pull/624
https://github.com/ghc-proposals/ghc-proposals/pull/624/files

I’d like to nominate Richard as the shepherd, given that he shepherded the
Linear Types. But if you have too much on your plate, feel free to reassign
to someone else.

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/


From mail at joachim-breitner.de  Fri Dec  8 17:54:30 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 08 Dec 2023 18:54:30 +0100
Subject: [ghc-steering-committee] GHC2024 voting
Message-ID: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>

Dear Committee,

there isn't much discussion, but maybe a silent consensus that we
should go ahead with this?

So please cast your vote about each of the following extensions; simply
by replying to this email and putting an x next to those extensions you
think should be part of GHC2024.

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

As per the process (#372) the quorum for inclusion is  _7 votes_ out of
the 10 current committee members. So it takes only four “no”s to block
an extension.

I’m putting GADTs in two both variants on the ballot.
If “GADTs with MonoLocalBinds” makes it in, then its in, and only if
not we look at “GADTs without MonoLocalBinds”.
So it may make sense to vote in favor of both.

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?

Thanks,
Joachim

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


From vlad.z.4096 at gmail.com  Fri Dec  8 18:02:56 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Fri, 8 Dec 2023 19:02:56 +0100
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
Message-ID: <CAHZ0NLrhfB=pSN=vDQpODsfOZmbxaHhBuyBX0mZN47EkeQ9pbw@mail.gmail.com>

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

Vlad

On Fri, Dec 8, 2023 at 6:54 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> there isn't much discussion, but maybe a silent consensus that we
> should go ahead with this?
>
> So please cast your vote about each of the following extensions; simply
> by replying to this email and putting an x next to those extensions you
> think should be part of GHC2024.
>
> * [ ] DataKinds
> * [ ] DefaultSignatures
> * [ ] DerivingStrategies
> * [ ] DisambiguateRecordFields
> * [ ] ExplicitNamespaces
> * [ ] GADTs with MonoLocalBinds
> * [ ] GADTs without MonoLocalBinds
> * [ ] LambdaCase
> * [ ] RoleAnnotations
> * [ ] TypeData
> * [ ] TypeFamilies
> * [ ] BlockArguments
>
> As per the process (#372) the quorum for inclusion is  _7 votes_ out of
> the 10 current committee members. So it takes only four “no”s to block
> an extension.
>
> I’m putting GADTs in two both variants on the ballot.
> If “GADTs with MonoLocalBinds” makes it in, then its in, and only if
> not we look at “GADTs without MonoLocalBinds”.
> So it may make sense to vote in favor of both.
>
> 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?
>
> 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/20231208/b2446dc3/attachment.html>

From mail at joachim-breitner.de  Sun Dec 10 19:44:46 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 10 Dec 2023 20:44:46 +0100
Subject: [ghc-steering-committee] Please review #626: Visible Forall in
	Types, Shepherd: Arnaud
Message-ID: <88c9e5837382c7b7a465ac521ffa54e5b6bf06bc.camel@joachim-breitner.de>

Dear Committee,

Vladislav proposes to support visible forall in types of terms better:
https://github.com/ghc-proposals/ghc-proposals/pull/626
https://github.com/ghc-proposals/ghc-proposals/pull/626/files


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,
Joachim



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


From arnaud.spiwack at tweag.io  Mon Dec 11 08:42:26 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 11 Dec 2023 09:42:26 +0100
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <CAHZ0NLrhfB=pSN=vDQpODsfOZmbxaHhBuyBX0mZN47EkeQ9pbw@mail.gmail.com>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
 <CAHZ0NLrhfB=pSN=vDQpODsfOZmbxaHhBuyBX0mZN47EkeQ9pbw@mail.gmail.com>
Message-ID: <CAGwnsn=mjg6+sF4rTt0GGN5XvGFKNmy-19Oq9bptY2MFKefyVQ@mail.gmail.com>

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

(for BlockArguments, I just can't bring myself to care either way. Don't
see this as a vote against: I simply have, in the most literal sense, no
opinion)

On Fri, 8 Dec 2023 at 19:03, Vladislav Zavialov <vlad.z.4096 at gmail.com>
wrote:

> * [ ] DataKinds
> * [ ] DefaultSignatures
> * [x] DerivingStrategies
> * [x] DisambiguateRecordFields
> * [ ] ExplicitNamespaces
> * [x] GADTs with MonoLocalBinds
> * [x] GADTs without MonoLocalBinds
> * [x] LambdaCase
> * [ ] RoleAnnotations
> * [ ] TypeData
> * [ ] TypeFamilies
> * [x] BlockArguments
>
> Vlad
>
> On Fri, Dec 8, 2023 at 6:54 PM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Dear Committee,
>>
>> there isn't much discussion, but maybe a silent consensus that we
>> should go ahead with this?
>>
>> So please cast your vote about each of the following extensions; simply
>> by replying to this email and putting an x next to those extensions you
>> think should be part of GHC2024.
>>
>> * [ ] DataKinds
>> * [ ] DefaultSignatures
>> * [ ] DerivingStrategies
>> * [ ] DisambiguateRecordFields
>> * [ ] ExplicitNamespaces
>> * [ ] GADTs with MonoLocalBinds
>> * [ ] GADTs without MonoLocalBinds
>> * [ ] LambdaCase
>> * [ ] RoleAnnotations
>> * [ ] TypeData
>> * [ ] TypeFamilies
>> * [ ] BlockArguments
>>
>> As per the process (#372) the quorum for inclusion is  _7 votes_ out of
>> the 10 current committee members. So it takes only four “no”s to block
>> an extension.
>>
>> I’m putting GADTs in two both variants on the ballot.
>> If “GADTs with MonoLocalBinds” makes it in, then its in, and only if
>> not we look at “GADTs without MonoLocalBinds”.
>> So it may make sense to vote in favor of both.
>>
>> 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?
>>
>> 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
>


-- 
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/20231211/690d1912/attachment.html>

From arnaud.spiwack at tweag.io  Mon Dec 11 09:55:25 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 11 Dec 2023 10:55:25 +0100
Subject: [ghc-steering-committee] #626: Amendment of Visible Forall in Types,
	recommendation: Accept
Message-ID: <CAGwnsnkpCa2NMPBPDd_hEA=vHQLbMzvtr78+EJsYQDa5Qcu+DQ@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231211/044ea5a1/attachment.html>

From simon.peytonjones at gmail.com  Mon Dec 11 10:06:09 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 11 Dec 2023 10:06:09 +0000
Subject: [ghc-steering-committee] #626: Amendment of Visible Forall in
 Types, recommendation: Accept
In-Reply-To: <CAGwnsnkpCa2NMPBPDd_hEA=vHQLbMzvtr78+EJsYQDa5Qcu+DQ@mail.gmail.com>
References: <CAGwnsnkpCa2NMPBPDd_hEA=vHQLbMzvtr78+EJsYQDa5Qcu+DQ@mail.gmail.com>
Message-ID: <CAJKmMz9+-xpr-X5V+4A=1Ctuvs9Xd+5oW8UgzRbZ8d=sQqU_tQ@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231211/df2dc2d0/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Dec 11 11:17:51 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 11 Dec 2023 11:17:51 +0000
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
Message-ID: <CAJKmMz9CpHqwwtb5aJEsm9-AMJY26M91cZrHXopykXdt7oq54A@mail.gmail.com>

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

On Fri, 8 Dec 2023 at 17:54, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> there isn't much discussion, but maybe a silent consensus that we
> should go ahead with this?
>
> So please cast your vote about each of the following extensions; simply
> by replying to this email and putting an x next to those extensions you
> think should be part of GHC2024.
>
> * [ ] DataKinds
> * [ ] DefaultSignatures
> * [ ] DerivingStrategies
> * [ ] DisambiguateRecordFields
> * [ ] ExplicitNamespaces
> * [ ] GADTs with MonoLocalBinds
> * [ ] GADTs without MonoLocalBinds
> * [ ] LambdaCase
> * [ ] RoleAnnotations
> * [ ] TypeData
> * [ ] TypeFamilies
> * [ ] BlockArguments
>
> As per the process (#372) the quorum for inclusion is  _7 votes_ out of
> the 10 current committee members. So it takes only four “no”s to block
> an extension.
>
> I’m putting GADTs in two both variants on the ballot.
> If “GADTs with MonoLocalBinds” makes it in, then its in, and only if
> not we look at “GADTs without MonoLocalBinds”.
> So it may make sense to vote in favor of both.
>
> 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?
>
> 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/20231211/32cc30c0/attachment.html>

From vlad.z.4096 at gmail.com  Mon Dec 11 12:39:49 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Mon, 11 Dec 2023 13:39:49 +0100
Subject: [ghc-steering-committee] Modifiers and #512: NoFieldSelectors
Message-ID: <CAHZ0NLpmzcMREu4vEtDZVqpeceH7SCECh3tC47OUTMu5okAQiQ@mail.gmail.com>

Dear Committee Members,

Our previous discussion regarding #512 was inconclusive.

Thread 1:
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

#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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231211/9d64ba7a/attachment.html>

From mail at joachim-breitner.de  Mon Dec 11 21:01:58 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 11 Dec 2023 22:01:58 +0100
Subject: [ghc-steering-committee] Modifiers and #512: NoFieldSelectors
In-Reply-To: <CAHZ0NLpmzcMREu4vEtDZVqpeceH7SCECh3tC47OUTMu5okAQiQ@mail.gmail.com>
References: <CAHZ0NLpmzcMREu4vEtDZVqpeceH7SCECh3tC47OUTMu5okAQiQ@mail.gmail.com>
Message-ID: <24106f9742d563e941efc27921be9da3a6f9a70a.camel@joachim-breitner.de>

Hi,

thanks for picking this up.


My initial thought after

Am Montag, dem 11.12.2023 um 13:39 +0100 schrieb Vladislav Zavialov:
> 2. The Modifiers proposal is, however, unimplemented

was that if nothing has moved here since a year (last thread was Dec
2022), then maybe it’s better to not hold NoFieldSelectors hostage, and
would have voted “Accept the proposal with pragma-based syntax, then
deprecate it and switch to modifiers-based syntax” (with an implicit “…
when and if modifiers becomes reality”).

But given 

> 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.

then “Revise the proposal to use modifiers-based syntax and then
accept” is plausible. So I’ll vote

* [x] 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
* [x] Revise the proposal to use modifiers-based syntax and then accept
* [ ] Reject the proposal regardless of syntax

Cheers,
Joachim

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


From simon.peytonjones at gmail.com  Mon Dec 11 21:31:27 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 11 Dec 2023 21:31:27 +0000
Subject: [ghc-steering-committee] Modifiers and #512: NoFieldSelectors
In-Reply-To: <CAHZ0NLpmzcMREu4vEtDZVqpeceH7SCECh3tC47OUTMu5okAQiQ@mail.gmail.com>
References: <CAHZ0NLpmzcMREu4vEtDZVqpeceH7SCECh3tC47OUTMu5okAQiQ@mail.gmail.com>
Message-ID: <CAJKmMz88uO4Y3W6RJR3b9qQNxg-30RPkLrkGYKJoBeLpJULn9g@mail.gmail.com>

>
> 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>
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
> Thread 2:
> 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
> _______________________________________________
> 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/20231211/0f2f9c27/attachment.html>

From rae at richarde.dev  Thu Dec 14 12:34:39 2023
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 14 Dec 2023 12:34:39 +0000
Subject: [ghc-steering-committee] Modifiers and #512: NoFieldSelectors
In-Reply-To: <CAJKmMz88uO4Y3W6RJR3b9qQNxg-30RPkLrkGYKJoBeLpJULn9g@mail.gmail.com>
References: <CAHZ0NLpmzcMREu4vEtDZVqpeceH7SCECh3tC47OUTMu5okAQiQ@mail.gmail.com>
 <CAJKmMz88uO4Y3W6RJR3b9qQNxg-30RPkLrkGYKJoBeLpJULn9g@mail.gmail.com>
Message-ID: <010f018c6852632f-a9b0eed2-0804-46a8-aa43-ff9ab3e1e50d-000000@us-east-2.amazonses.com>

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> 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
> _______________________________________________
> 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
> 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/20231214/d5fb88b5/attachment.html>

From marlowsd at gmail.com  Sat Dec 16 13:16:11 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 16 Dec 2023 13:16:11 +0000
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
Message-ID: <CANsrgPJ29HNwAUMRqB94eDNJpZDtLsDJbeeN=JPLFXrcXeL3kA@mail.gmail.com>

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

On Fri, 8 Dec 2023 at 17:54, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> there isn't much discussion, but maybe a silent consensus that we
> should go ahead with this?
>
> So please cast your vote about each of the following extensions; simply
> by replying to this email and putting an x next to those extensions you
> think should be part of GHC2024.
>
> * [ ] DataKinds
> * [ ] DefaultSignatures
> * [ ] DerivingStrategies
> * [ ] DisambiguateRecordFields
> * [ ] ExplicitNamespaces
> * [ ] GADTs with MonoLocalBinds
> * [ ] GADTs without MonoLocalBinds
> * [ ] LambdaCase
> * [ ] RoleAnnotations
> * [ ] TypeData
> * [ ] TypeFamilies
> * [ ] BlockArguments
>
> As per the process (#372) the quorum for inclusion is  _7 votes_ out of
> the 10 current committee members. So it takes only four “no”s to block
> an extension.
>
> I’m putting GADTs in two both variants on the ballot.
> If “GADTs with MonoLocalBinds” makes it in, then its in, and only if
> not we look at “GADTs without MonoLocalBinds”.
> So it may make sense to vote in favor of both.
>
> 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?
>
> 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/20231216/e6743a10/attachment.html>

From adam at well-typed.com  Sun Dec 17 21:24:28 2023
From: adam at well-typed.com (Adam Gundry)
Date: Sun, 17 Dec 2023 21:24:28 +0000
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <CANsrgPJ29HNwAUMRqB94eDNJpZDtLsDJbeeN=JPLFXrcXeL3kA@mail.gmail.com>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
 <CANsrgPJ29HNwAUMRqB94eDNJpZDtLsDJbeeN=JPLFXrcXeL3kA@mail.gmail.com>
Message-ID: <3c1a93ee-929f-4e81-8ec8-a73904db4818@well-typed.com>

Sorry for my slow response. A few observations, and my vote:

The proposal mentions ImpredicativeTypes, but it doesn't seem to appear 
on the ballot? (Personally I'm not in favour of including it, but was 
this an accidental omission?)

I feel strongly that enabling GHC2024 should be equivalent to enabling 
all its constituent extensions (which is not the case for GHC2021, e.g. 
because -XTypeOperators enables ExplicitNamespaces but -XGHC2021 does 
not). This motivates including ExplicitNamespaces and GADTs with 
MonoLocalBinds. Alternatively, if the collective opinion is that GADTs 
should not be included, I believe we should seriously consider removing 
ExistentialQuantification.

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

Cheers,

Adam


On 16/12/2023 13:16, Simon Marlow wrote:
> * [x] DataKinds
> * [x] DefaultSignatures
> * [x] DerivingStrategies
> * [x] DisambiguateRecordFields
> * [x] ExplicitNamespaces
> * [x] GADTs with MonoLocalBinds
> * [x] GADTs without MonoLocalBinds
> * [x] LambdaCase
> * [x] RoleAnnotations
> * [ ] TypeData
> * [x] TypeFamilies
> * [ ] BlockArguments
> 
> On Fri, 8 Dec 2023 at 17:54, Joachim Breitner <mail at joachim-breitner.de 
> <mailto:mail at joachim-breitner.de>> wrote:
> 
>     Dear Committee,
> 
>     there isn't much discussion, but maybe a silent consensus that we
>     should go ahead with this?
> 
>     So please cast your vote about each of the following extensions; simply
>     by replying to this email and putting an x next to those extensions you
>     think should be part of GHC2024.
> 
>     * [ ] DataKinds
>     * [ ] DefaultSignatures
>     * [ ] DerivingStrategies
>     * [ ] DisambiguateRecordFields
>     * [ ] ExplicitNamespaces
>     * [ ] GADTs with MonoLocalBinds
>     * [ ] GADTs without MonoLocalBinds
>     * [ ] LambdaCase
>     * [ ] RoleAnnotations
>     * [ ] TypeData
>     * [ ] TypeFamilies
>     * [ ] BlockArguments
> 
>     As per the process (#372) the quorum for inclusion is  _7 votes_ out of
>     the 10 current committee members. So it takes only four “no”s to block
>     an extension.
> 
>     I’m putting GADTs in two both variants on the ballot.
>     If “GADTs with MonoLocalBinds” makes it in, then its in, and only if
>     not we look at “GADTs without MonoLocalBinds”.
>     So it may make sense to vote in favor of both.
> 
>     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?
> 
>     Thanks,
>     Joachim
> 
>     -- 
>     Joachim Breitner
>     mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>     http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>


-- 
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 lists at richarde.dev  Mon Dec 18 02:54:24 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 18 Dec 2023 02:54:24 +0000
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
Message-ID: <010f018c7ad89976-62c507f4-ad42-4bc6-8e9e-d0d7cd18d787-000000@us-east-2.amazonses.com>



> On Dec 8, 2023, at 12:54 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> * [X ] DataKinds
> * [X ] DefaultSignatures
> * [X ] DerivingStrategies
> * [X ] DisambiguateRecordFields
> * [X ] ExplicitNamespaces
> * [X ] GADTs with MonoLocalBinds
> * [X ] GADTs without MonoLocalBinds 
> * [X ] LambdaCase
> * [X ] RoleAnnotations
> * [X ] TypeData
> * [X ] TypeFamilies
> * [X ] BlockArguments

Rationale: These are all stable extensions. With the exception of MonoLocalBinds, none of these affect any existing programs. And for MonoLocalBinds, we've been traveling in the direction of it for a long time -- let's arrive. My understanding is that this change won't affect any package whose cabal file declares a default-language. If that's wrong, then I withdraw the suggestion; I would not want this to be backward-incompatible with released packages.

Richard

From mail at joachim-breitner.de  Mon Dec 18 08:08:37 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 18 Dec 2023 09:08:37 +0100
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <3c1a93ee-929f-4e81-8ec8-a73904db4818@well-typed.com>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
 <CANsrgPJ29HNwAUMRqB94eDNJpZDtLsDJbeeN=JPLFXrcXeL3kA@mail.gmail.com>
 <3c1a93ee-929f-4e81-8ec8-a73904db4818@well-typed.com>
Message-ID: <4bcbb410199c67a6f6b5d6f88017f0d9deab8ed0.camel@joachim-breitner.de>

Hi,

Am Sonntag, dem 17.12.2023 um 21:24 +0000 schrieb Adam Gundry:
> The proposal mentions ImpredicativeTypes, but it doesn't seem to appear 
> on the ballot? (Personally I'm not in favour of including it, but was 
> this an accidental omission?)

pure clerical error on my side, not sure how it happened.  Sorry Arnaud
(who proposed it).

I guess it’s only fair to ask everyone to also cast a vote on
ImpredicativeTypes. Sorry for the extra round-trip.

Adam not in favor, I take.

Cheers,
Joachim

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


From arnaud.spiwack at tweag.io  Mon Dec 18 08:53:37 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 18 Dec 2023 09:53:37 +0100
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <4bcbb410199c67a6f6b5d6f88017f0d9deab8ed0.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
 <CANsrgPJ29HNwAUMRqB94eDNJpZDtLsDJbeeN=JPLFXrcXeL3kA@mail.gmail.com>
 <3c1a93ee-929f-4e81-8ec8-a73904db4818@well-typed.com>
 <4bcbb410199c67a6f6b5d6f88017f0d9deab8ed0.camel@joachim-breitner.de>
Message-ID: <CAGwnsnn3j0JU_NfCRCTcvGFFxgrD+0sdOCG+ZibGLDicQaJ02Q@mail.gmail.com>

I'm in favour of impredicative types, to everybody's surprise :-) .

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

> Hi,
>
> Am Sonntag, dem 17.12.2023 um 21:24 +0000 schrieb Adam Gundry:
> > The proposal mentions ImpredicativeTypes, but it doesn't seem to appear
> > on the ballot? (Personally I'm not in favour of including it, but was
> > this an accidental omission?)
>
> pure clerical error on my side, not sure how it happened.  Sorry Arnaud
> (who proposed it).
>
> I guess it’s only fair to ask everyone to also cast a vote on
> ImpredicativeTypes. Sorry for the extra round-trip.
>
> Adam not in favor, I take.
>
> 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
>


-- 
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/20231218/803cb2a6/attachment.html>

From arnaud.spiwack at tweag.io  Mon Dec 18 08:59:30 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 18 Dec 2023 09:59:30 +0100
Subject: [ghc-steering-committee] Modifiers and #512: NoFieldSelectors
In-Reply-To: <010f018c6852632f-a9b0eed2-0804-46a8-aa43-ff9ab3e1e50d-000000@us-east-2.amazonses.com>
References: <CAHZ0NLpmzcMREu4vEtDZVqpeceH7SCECh3tC47OUTMu5okAQiQ@mail.gmail.com>
 <CAJKmMz88uO4Y3W6RJR3b9qQNxg-30RPkLrkGYKJoBeLpJULn9g@mail.gmail.com>
 <010f018c6852632f-a9b0eed2-0804-46a8-aa43-ff9ab3e1e50d-000000@us-east-2.amazonses.com>
Message-ID: <CAGwnsn=_si=gPozgPaLf+DYq=8QVVccpD+Pr_+aPHhAdEkiFxg@mail.gmail.com>

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> 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> 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>
> 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
>> Thread 2:
>> 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
>> _______________________________________________
>> 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
>


-- 
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/20231218/8fcaa370/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Dec 18 10:26:42 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 18 Dec 2023 10:26:42 +0000
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <4bcbb410199c67a6f6b5d6f88017f0d9deab8ed0.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
 <CANsrgPJ29HNwAUMRqB94eDNJpZDtLsDJbeeN=JPLFXrcXeL3kA@mail.gmail.com>
 <3c1a93ee-929f-4e81-8ec8-a73904db4818@well-typed.com>
 <4bcbb410199c67a6f6b5d6f88017f0d9deab8ed0.camel@joachim-breitner.de>
Message-ID: <CAJKmMz8n8dXd_gr9DS7V+r9NMVmcLORWVXXXX7Mq79NCZKNxFA@mail.gmail.com>

 ImpredicativeTypes has been very successful, I think (i.e. few bug
reports), and very non-disruptive (i.e even if it's on, code that doesn't
use it goes on working).

But still, I would give it a longer "outing" before having it on by default.

So I'm mildly against.  I'd put it on in the next iteration.  But I don't
feel strongly.

Simon

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

> Hi,
>
> Am Sonntag, dem 17.12.2023 um 21:24 +0000 schrieb Adam Gundry:
> > The proposal mentions ImpredicativeTypes, but it doesn't seem to appear
> > on the ballot? (Personally I'm not in favour of including it, but was
> > this an accidental omission?)
>
> pure clerical error on my side, not sure how it happened.  Sorry Arnaud
> (who proposed it).
>
> I guess it’s only fair to ask everyone to also cast a vote on
> ImpredicativeTypes. Sorry for the extra round-trip.
>
> Adam not in favor, I take.
>
> 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/20231218/96552508/attachment.html>

From simon.peytonjones at gmail.com  Mon Dec 18 10:36:52 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 18 Dec 2023 10:36:52 +0000
Subject: [ghc-steering-committee] #493: SPECIALISE with expressions,
	rec: accept
In-Reply-To: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com>
References: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com>
Message-ID: <CAJKmMz-t6=D--9zWbuNotpJbdmx0q12fiO0=jYrAic4ykx8-1A@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231218/7572a8f4/attachment.html>

From mail at joachim-breitner.de  Mon Dec 18 16:01:51 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 18 Dec 2023 17:01:51 +0100
Subject: [ghc-steering-committee]   Please review #625: Stability Goals,
 Shepherd: Moritz
Message-ID: <1ef858b4eb70f0535f2802cc19e8d772e655511a.camel@joachim-breitner.de>

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/


From eric at seidel.io  Tue Dec 19 03:02:14 2023
From: eric at seidel.io (Eric Seidel)
Date: Mon, 18 Dec 2023 21:02:14 -0600
Subject: [ghc-steering-committee] #493: SPECIALISE with expressions,
	rec: accept
In-Reply-To: <CAJKmMz-t6=D--9zWbuNotpJbdmx0q12fiO0=jYrAic4ykx8-1A@mail.gmail.com>
References: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com>
 <CAJKmMz-t6=D--9zWbuNotpJbdmx0q12fiO0=jYrAic4ykx8-1A@mail.gmail.com>
Message-ID: <beba9def-eddd-4b52-b676-8e2509c66dba@app.fastmail.com>

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

From rae at richarde.dev  Tue Dec 19 12:54:53 2023
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 19 Dec 2023 12:54:53 +0000
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <CAJKmMz8n8dXd_gr9DS7V+r9NMVmcLORWVXXXX7Mq79NCZKNxFA@mail.gmail.com>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
 <CANsrgPJ29HNwAUMRqB94eDNJpZDtLsDJbeeN=JPLFXrcXeL3kA@mail.gmail.com>
 <3c1a93ee-929f-4e81-8ec8-a73904db4818@well-typed.com>
 <4bcbb410199c67a6f6b5d6f88017f0d9deab8ed0.camel@joachim-breitner.de>
 <CAJKmMz8n8dXd_gr9DS7V+r9NMVmcLORWVXXXX7Mq79NCZKNxFA@mail.gmail.com>
Message-ID: <010f018c8224b7e6-e981d019-efed-4a53-9421-3a527534dcc8-000000@us-east-2.amazonses.com>

I'll join with Simon here. It's a bit too fresh for me.

Richard

> On Dec 18, 2023, at 5:26 AM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> ImpredicativeTypes has been very successful, I think (i.e. few bug reports), and very non-disruptive (i.e even if it's on, code that doesn't use it goes on working).   
> 
> But still, I would give it a longer "outing" before having it on by default.
> 
> So I'm mildly against.  I'd put it on in the next iteration.  But I don't feel strongly.
> 
> Simon
> 
> On Mon, 18 Dec 2023 at 08:09, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> Am Sonntag, dem 17.12.2023 um 21:24 +0000 schrieb Adam Gundry:
> > The proposal mentions ImpredicativeTypes, but it doesn't seem to appear 
> > on the ballot? (Personally I'm not in favour of including it, but was 
> > this an accidental omission?)
> 
> pure clerical error on my side, not sure how it happened.  Sorry Arnaud
> (who proposed it).
> 
> I guess it’s only fair to ask everyone to also cast a vote on
> ImpredicativeTypes. Sorry for the extra round-trip.
> 
> Adam not in favor, I take.
> 
> Cheers,
> Joachim
> 
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.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 <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/20231219/15bebf18/attachment.html>

From simon.peytonjones at gmail.com  Fri Dec 22 11:46:31 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Dec 2023 11:46:31 +0000
Subject: [ghc-steering-committee] GHC stability
Message-ID: <CAJKmMz_m6rrXobk41TcHUhYtOU1iS0C3F=MDTyu5BQ-PK9Fajw@mail.gmail.com>

Dear Jose, GHC Steering Group, and HF Stability Group

There has been quite a lot of recent discussion about actions we could take
to promote GHC stability.  In an effort to gather these threads together I
have written

*GHC Staibility State of Play*
<https://docs.google.com/document/d/1sX_rXHx8Mj3Kae9GalR2BwZ5-xzl7UpnpMBwl4dqsWY/edit?usp=sharing>

It articulates the Big Goal, and some discussions that are going on around
it.

Jose, I think that the Big Goal could be a helpful focus for HF.   I'm not
sure which of the strands is highest priority (causes most friction for
users) so HF's guidance about that would be helpful.

It would be great to move some of this forward.

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

From mail at joachim-breitner.de  Fri Dec 22 12:47:31 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 22 Dec 2023 13:47:31 +0100
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
Message-ID: <6079b11bea4df8d92788da6bdbf8a960dfcf6606.camel@joachim-breitner.de>

Hi,

just a reminder that the polling is still ongoing, and with 6 votes in
I’m looking forward to receiving the votes from Moritz, Chris and Eric.

Since the quorum for inclusion is 7 votes, 4 nay votes suffice to kick
something out. This means that according to my counting, TypeData and
BlockArguments are already out.

Cheers,
Joachim



Am Freitag, dem 08.12.2023 um 18:54 +0100 schrieb Joachim Breitner:
> Dear Committee,
> 
> there isn't much discussion, but maybe a silent consensus that we
> should go ahead with this?
> 
> So please cast your vote about each of the following extensions; simply
> by replying to this email and putting an x next to those extensions you
> think should be part of GHC2024.
> 
> * [ ] DataKinds
> * [ ] DefaultSignatures
> * [ ] DerivingStrategies
> * [ ] DisambiguateRecordFields
> * [ ] ExplicitNamespaces
> * [ ] GADTs with MonoLocalBinds
> * [ ] GADTs without MonoLocalBinds 
> * [ ] LambdaCase
> * [ ] RoleAnnotations
> * [ ] TypeData
> * [ ] TypeFamilies
> * [ ] BlockArguments
> 
> As per the process (#372) the quorum for inclusion is  _7 votes_ out of
> the 10 current committee members. So it takes only four “no”s to block
> an extension.
> 
> I’m putting GADTs in two both variants on the ballot.
> If “GADTs with MonoLocalBinds” makes it in, then its in, and only if
> not we look at “GADTs without MonoLocalBinds”.
> So it may make sense to vote in favor of both.
> 
> 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?
> 
> Thanks,
> Joachim
> 

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


From mail at joachim-breitner.de  Fri Dec 22 12:52:50 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 22 Dec 2023 13:52:50 +0100
Subject: [ghc-steering-committee] GHC Committe Chairs term
Message-ID: <e7329f91b2c97381dd2e1ab9ace476c68e0163c2.camel@joachim-breitner.de>

Dear Simon and Simon,

your current three terms on the committee end soon (Feb 2024). The
bylaws say that you will stay on the committee without renomination and
electing if you wish to do so (and the rest of the committee agrees
with majority).

Therefore I ask: do you want to stay on the committee for another term?


(If you do I already register my vote to support this outcome, with
four more such votes from non-chair-members we’ll have fulfilled this
little ceremony.)

Cheers,
Joachim


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


From simon.peytonjones at gmail.com  Fri Dec 22 13:08:30 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Dec 2023 13:08:30 +0000
Subject: [ghc-steering-committee] GHC Committe Chairs term
In-Reply-To: <e7329f91b2c97381dd2e1ab9ace476c68e0163c2.camel@joachim-breitner.de>
References: <e7329f91b2c97381dd2e1ab9ace476c68e0163c2.camel@joachim-breitner.de>
Message-ID: <CAJKmMz_WG62+8_EaaaQ65_X1Zwaq8SfVU65zspx1JsHqBwB+PA@mail.gmail.com>

I am willing -- but also happy to step down if other possibilities exist.
Other things being equal, rotating leadership is good practice.

For example, Joachim would make an excellent chair.

Simon

On Fri, 22 Dec 2023 at 12:53, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Simon and Simon,
>
> your current three terms on the committee end soon (Feb 2024). The
> bylaws say that you will stay on the committee without renomination and
> electing if you wish to do so (and the rest of the committee agrees
> with majority).
>
> Therefore I ask: do you want to stay on the committee for another term?
>
>
> (If you do I already register my vote to support this outcome, with
> four more such votes from non-chair-members we’ll have fulfilled this
> little ceremony.)
>
> 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/20231222/85e402fe/attachment.html>

From marlowsd at gmail.com  Fri Dec 22 13:14:19 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 22 Dec 2023 13:14:19 +0000
Subject: [ghc-steering-committee] GHC Committe Chairs term
In-Reply-To: <CAJKmMz_WG62+8_EaaaQ65_X1Zwaq8SfVU65zspx1JsHqBwB+PA@mail.gmail.com>
References: <e7329f91b2c97381dd2e1ab9ace476c68e0163c2.camel@joachim-breitner.de>
 <CAJKmMz_WG62+8_EaaaQ65_X1Zwaq8SfVU65zspx1JsHqBwB+PA@mail.gmail.com>
Message-ID: <CANsrgPLsjcA=eZekod+4gjUTiPzASuBPxoC1zdOmyT8EuadKjQ@mail.gmail.com>

Same here.

Cheers
Simon

On Fri, 22 Dec 2023 at 13:09, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I am willing -- but also happy to step down if other possibilities exist.
> Other things being equal, rotating leadership is good practice.
>
> For example, Joachim would make an excellent chair.
>
> Simon
>
> On Fri, 22 Dec 2023 at 12:53, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Dear Simon and Simon,
>>
>> your current three terms on the committee end soon (Feb 2024). The
>> bylaws say that you will stay on the committee without renomination and
>> electing if you wish to do so (and the rest of the committee agrees
>> with majority).
>>
>> Therefore I ask: do you want to stay on the committee for another term?
>>
>>
>> (If you do I already register my vote to support this outcome, with
>> four more such votes from non-chair-members we’ll have fulfilled this
>> little ceremony.)
>>
>> 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/20231222/67ba35f4/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec 22 14:20:36 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 22 Dec 2023 15:20:36 +0100
Subject: [ghc-steering-committee] #626: Amendment of Visible Forall in
 Types, recommendation: Accept
In-Reply-To: <CAJKmMz9+-xpr-X5V+4A=1Ctuvs9Xd+5oW8UgzRbZ8d=sQqU_tQ@mail.gmail.com>
References: <CAGwnsnkpCa2NMPBPDd_hEA=vHQLbMzvtr78+EJsYQDa5Qcu+DQ@mail.gmail.com>
 <CAJKmMz9+-xpr-X5V+4A=1Ctuvs9Xd+5oW8UgzRbZ8d=sQqU_tQ@mail.gmail.com>
Message-ID: <CAGwnsnkM7FPRAXeTik5g2Na3s+Dzv2ifAhkzpukydaQ8Hz0NTQ@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231222/03f81efa/attachment-0001.html>

From eric at seidel.io  Wed Dec 27 15:22:37 2023
From: eric at seidel.io (Eric Seidel)
Date: Wed, 27 Dec 2023 09:22:37 -0600
Subject: [ghc-steering-committee] GHC2024 voting
In-Reply-To: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
References: <8512abce8c11345397ac54c079cab3e084d8dc94.camel@joachim-breitner.de>
Message-ID: <31d4df53-43f9-413c-99e1-1776dd73533f@app.fastmail.com>

These all seem like sensible additions to me, and I agree we should pull the trigger on MonoLocalBinds.

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

On Fri, Dec 8, 2023, at 11:54, Joachim Breitner wrote:
> Dear Committee,
>
> there isn't much discussion, but maybe a silent consensus that we
> should go ahead with this?
>
> So please cast your vote about each of the following extensions; simply
> by replying to this email and putting an x next to those extensions you
> think should be part of GHC2024.
>
> * [ ] DataKinds
> * [ ] DefaultSignatures
> * [ ] DerivingStrategies
> * [ ] DisambiguateRecordFields
> * [ ] ExplicitNamespaces
> * [ ] GADTs with MonoLocalBinds
> * [ ] GADTs without MonoLocalBinds 
> * [ ] LambdaCase
> * [ ] RoleAnnotations
> * [ ] TypeData
> * [ ] TypeFamilies
> * [ ] BlockArguments
>
> As per the process (#372) the quorum for inclusion is  _7 votes_ out of
> the 10 current committee members. So it takes only four “no”s to block
> an extension.
>
> I’m putting GADTs in two both variants on the ballot.
> If “GADTs with MonoLocalBinds” makes it in, then its in, and only if
> not we look at “GADTs without MonoLocalBinds”.
> So it may make sense to vote in favor of both.
>
> 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?
>
> 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

From eric at seidel.io  Wed Dec 27 19:23:43 2023
From: eric at seidel.io (Eric Seidel)
Date: Wed, 27 Dec 2023 13:23:43 -0600
Subject: [ghc-steering-committee] Proposal #569: multiline string literals;
	Rec: accept
In-Reply-To: <a014e8f0d68ec103abb248a6ddf335006df1f9ca.camel@joachim-breitner.de>
References: <a014e8f0d68ec103abb248a6ddf335006df1f9ca.camel@joachim-breitner.de>
Message-ID: <6c390157-cffc-4284-86a2-8f2d2458a8df@app.fastmail.com>

Dear Committee,

Brandon Chinn has proposed[1] adding multi-line strings to Haskell. Most languages these days support multi-line strings, even Java has them as of Java 17 (which coincidentally is a strong inspiration for Brandon's proposal). Yet in Haskell we have to resort to tricks like `unlines`  or quasiquoters.

Brandon's proposal adds support for triple-quote delimited multi-line strings, e.g.

```
adtParseJSON =
  """
  \\v -> case v of
    Aeson.Null -> pure PrintStyleInherit
    Aeson.String "" -> pure PrintStyleInherit
    _ -> PrintStyleOverride <$> Aeson.parseJSON v
  """
```

The rules are largely inspired by Java's text blocks[2] proposal, which I've also read and find very pragmatic. Honestly, I encourage the Committee to read the Java proposal as well. Haskell innovates in many areas of language design, but the lexical structure of strings feels like an area where we should conserve our innovation tokens. Brandon's proposal does a great job here of starting from an established baseline and adapting it to Haskell's idiosyncrasies. 

One point I would draw the Committee's attention to is the handling of characters on the opening line[3]. My only concern with this proposal is that omitting the opening line from the prefix calculation can lead to some counterintuitive behavior. For example

```
s = """ foo
        bar
    """
```

would be parsed as `" foo\nbar"`. I'm on the fence about whether we should try to be more prescriptive here, or just expect that Haskeller's will learn to avoid this corner case. I think it's probably fine.

On balance I think we should accept the proposal.

Thanks!
Eric

[1]: https://github.com/ghc-proposals/ghc-proposals/pull/569
[2]: https://openjdk.org/jeps/378
[3]: https://github.com/brandonchinn178/ghc-proposals/blob/multiline-strings/proposals/0569-multiline-strings.rst#33ignore-leading-characters

From rae at richarde.dev  Fri Dec 29 13:19:05 2023
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 29 Dec 2023 13:19:05 +0000
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <6c390157-cffc-4284-86a2-8f2d2458a8df@app.fastmail.com>
References: <a014e8f0d68ec103abb248a6ddf335006df1f9ca.camel@joachim-breitner.de>
 <6c390157-cffc-4284-86a2-8f2d2458a8df@app.fastmail.com>
Message-ID: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>

I'm pretty agnostic on the whitespace-stripping details here. I think Haskellers will learn to deal with whatever is decided, so I think the choice is pretty low stakes.

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. Yet I don't want the perfect to become the enemy of the good, so I vote for acceptance.

Richard

> On Dec 27, 2023, at 2:23 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> Dear Committee,
> 
> Brandon Chinn has proposed[1] adding multi-line strings to Haskell. Most languages these days support multi-line strings, even Java has them as of Java 17 (which coincidentally is a strong inspiration for Brandon's proposal). Yet in Haskell we have to resort to tricks like `unlines`  or quasiquoters.
> 
> Brandon's proposal adds support for triple-quote delimited multi-line strings, e.g.
> 
> ```
> adtParseJSON =
>  """
>  \\v -> case v of
>    Aeson.Null -> pure PrintStyleInherit
>    Aeson.String "" -> pure PrintStyleInherit
>    _ -> PrintStyleOverride <$> Aeson.parseJSON v
>  """
> ```
> 
> The rules are largely inspired by Java's text blocks[2] proposal, which I've also read and find very pragmatic. Honestly, I encourage the Committee to read the Java proposal as well. Haskell innovates in many areas of language design, but the lexical structure of strings feels like an area where we should conserve our innovation tokens. Brandon's proposal does a great job here of starting from an established baseline and adapting it to Haskell's idiosyncrasies. 
> 
> One point I would draw the Committee's attention to is the handling of characters on the opening line[3]. My only concern with this proposal is that omitting the opening line from the prefix calculation can lead to some counterintuitive behavior. For example
> 
> ```
> s = """ foo
>        bar
>    """
> ```
> 
> would be parsed as `" foo\nbar"`. I'm on the fence about whether we should try to be more prescriptive here, or just expect that Haskeller's will learn to avoid this corner case. I think it's probably fine.
> 
> On balance I think we should accept the proposal.
> 
> Thanks!
> Eric
> 
> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/569
> [2]: https://openjdk.org/jeps/378
> [3]: https://github.com/brandonchinn178/ghc-proposals/blob/multiline-strings/proposals/0569-multiline-strings.rst#33ignore-leading-characters
> _______________________________________________
> 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  Sun Dec 31 10:40:15 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 31 Dec 2023 11:40:15 +0100 (GMT+01:00)
Subject: [ghc-steering-committee]  Proposal #569: multiline string literals;
	Rec: accept
In-Reply-To: <6c390157-cffc-4284-86a2-8f2d2458a8df@app.fastmail.com>
References: <a014e8f0d68ec103abb248a6ddf335006df1f9ca.camel@joachim-breitner.de>
 <6c390157-cffc-4284-86a2-8f2d2458a8df@app.fastmail.com>
Message-ID: <8a9a56f4-f5fa-453f-83ae-0b96b0e11deb@joachim-breitner.de>

Hi,

thanks for the good analysis and recommendation, happy to follow suit. The color of the shed is less important than that the bikes stay dry.

Cheers,
Joachim

From moritz.angermann at gmail.com  Sun Dec 31 12:10:56 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 31 Dec 2023 08:10:56 -0400
Subject: [ghc-steering-committee] Proposal #569: multiline string
 literals; Rec: accept
In-Reply-To: <8a9a56f4-f5fa-453f-83ae-0b96b0e11deb@joachim-breitner.de>
References: <a014e8f0d68ec103abb248a6ddf335006df1f9ca.camel@joachim-breitner.de>
 <6c390157-cffc-4284-86a2-8f2d2458a8df@app.fastmail.com>
 <8a9a56f4-f5fa-453f-83ae-0b96b0e11deb@joachim-breitner.de>
Message-ID: <CAKfdd-zYQ=HOY-ppe_iXWy+cF1MR6omsqNjggXMMBG1aPKEMHA@mail.gmail.com>

I’m generally in favor of this! Do we consider this experimental or stable?
Does the author intent to make breaking changes without or with
warning/deprecation cycles? Do we expect to see changes based on community
feedback once this is available in some form to the working developer?

Cheers,
  Moritz

On Sun, 31 Dec 2023 at 6:40 AM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> thanks for the good analysis and recommendation, happy to follow suit. The
> color of the shed is less important than that the bikes stay dry.
>
> Cheers,
> Joachim
> _______________________________________________
> 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/20231231/a2f2d652/attachment.html>

From eric at seidel.io  Sun Dec 31 17:04:59 2023
From: eric at seidel.io (Eric Seidel)
Date: Sun, 31 Dec 2023 11:04:59 -0600
Subject: [ghc-steering-committee] Proposal #569: multiline string
	literals; Rec: accept
In-Reply-To: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
References: <010f018cb5ba765f-23ea0d74-624e-4d66-862f-400038a9fa5a-000000@us-east-2.amazonses.com>
Message-ID: <17392B90-3DD3-48C7-8E40-8DF3179702AA@seidel.io>


> 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.