From sgraf1337 at gmail.com  Fri Nov  1 17:00:42 2024
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Fri, 01 Nov 2024 17:00:42 +0000
Subject: [ghc-steering-committee] Please review #673: Amendment to -jsem
 proposal #540
In-Reply-To: <CAJKmMz-T=7m=ypVsvXOOjnaBanUfdA2YeknLTZZQTha2d1hFWg@mail.gmail.com>
References: <cafec484-0ca7-4f0c-8949-992e9c115537@well-typed.com>
 <20240920100038.f2cc7a353c4b4ce02da189f2@mega-nerd.com>
 <86d15bf6-a4e1-4b5f-bf49-de7f88496f32@app.fastmail.com>
 <i46tbqu3ptd36vlc4sgsckpycry6uzispkp7ksi6i34nfiwoo5@hera.m-0.eu>
 <CAJKmMz8K8twpXOC2uZD8xH006Oi-nt+28q=j+BZkCGW8Ds9zuw@mail.gmail.com>
 <CAGwnsn=nNKX+bh+CWD_dd4N0HTGzBTBnB5oTTKTyp_TNS7_vnA@mail.gmail.com>
 <em63aabb01-6ad6-43e5-b597-afad17fe0a94@ad1f818c.com>
 <c27ff99d-02ab-43ff-b503-4ef3151b8fe5@well-typed.com>
 <CAJKmMz-T=7m=ypVsvXOOjnaBanUfdA2YeknLTZZQTha2d1hFWg@mail.gmail.com>
Message-ID: <emdd6cd63f-b21f-4eb1-9ccd-9d4a43f5cb1d@f217a969.com>

I'm in support as well, but would like to see the relationship to PVP 
major bumps addressed.


------ Originalnachricht ------
Von "Simon Peyton Jones" <simon.peytonjones at gmail.com>
An "Adam Gundry" <adam at well-typed.com>
Cc ghc-steering-committee at haskell.org
Datum 29.10.2024 23:16:20
Betreff Re: [ghc-steering-committee] Please review #673: Amendment to 
-jsem proposal #540

>I'm supportive.   I do not have a well-informed view, but the amendment 
>is born from practical experience, so I am pretty sure it's an 
>improvement.
>
>I'd love a bit more detail in the proposal (I have commented in one 
>place) but I might be off-target and would yield to others' advice, 
>including that of the author.
>
>Simon
>
>On Tue, 29 Oct 2024 at 19:37, Adam Gundry <adam at well-typed.com> wrote:
>>It seems Zubin updated the proposal to take account of Sebastian's
>>concerns, but then discussion has tailed off. Are we now in a position
>>to accept this proposal, or are there any remaining concerns?
>>
>>Cheers,
>>
>>Adam
>>
>>
>>
>>On 24/09/2024 07:44, Sebastian Graf wrote:
>> > I think changes to the communication protocol *are* user-facing, in 
>>that
>> > any change to the protocol could implies a breaking change between 
>>all
>> > cabal releases in the future and all GHC releases in the past.
>> > It appears that is the case for the planned release of
>> > `semaphore-compat-2`, but I'm not 100% sure.
>> >
>> > In that light, I think it's good to discuss in a proposal to ensure 
>>we
>> > do not sign off lightly on such breaking changes, in particular for
>> > future versions of `semaphore-compat`.
>> >
>> > I will express support once compatibility and breaking changes are
>> > properly addressed.
>> >
>> > Sebastian
>> >
>> > ------ Originalnachricht ------
>> > Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io
>> > <mailto:arnaud.spiwack at tweag.io>>
>> > An "Simon Peyton Jones" <simon.peytonjones at gmail.com
>> > <mailto:simon.peytonjones at gmail.com>>
>> > Cc ghc-steering-committee at haskell.org
>> > <mailto:ghc-steering-committee at haskell.org>
>> > Datum 24.09.2024 04:17:17
>> > Betreff Re: [ghc-steering-committee] Please review #673: Amendment 
>>to
>> > -jsem proposal #540
>> >
>> >> Quite frankly, this is barely any user-facing change at all.
>> >> Technically the semaphore could previously be shared by non-Haskell
>> >> processes in ways the updated proposal doesn't allow. But it's not
>> >> really something people do. So it all sounds reasonable.
>> >>
>> >> On Mon, 23 Sept 2024 at 19:10, Simon Peyton Jones
>> >> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> 
>>wrote:
>> >>
>> >>     I'm happy to support too, but I would like to see 
>>presentational
>> >>     changes, so the final proposal makes sense when read in 5 yrs 
>>time.
>> >>
>> >>     Simon
>> >>
>> >>     On Sat, 21 Sept 2024 at 20:45, Malte Ott <malte.ott at maralorn.de
>> >>     <mailto:malte.ott at maralorn.de>> wrote:
>> >>
>> >>         I agree.
>> >>
>> >>         On 2024-09-21 09:16, Eric Seidel wrote:
>> >>         > Hi all,
>> >>         >
>> >>         > This seems like a sensible update to an accepted 
>>proposal.
>> >>         >
>> >>         > I recommend we accept the amendment.
>> >>         >
>> >>         > Eric
>> >>         >
>> >>         > On Thu, Sep 19, 2024, at 19:00, Erik de Castro Lopo 
>>wrote:
>> >>         > > Hi all,
>> >>         > >
>> >>         > > This is minor updates to correct an existing approved
>> >>         proposal.
>> >>         > >
>> >>         > > I approve of these changes.
>> >>         > >
>> >>         > > Erik
>> >>         > >
>> >>         > > Adam Gundry wrote:
>> >>         > >
>> >>         > >> Dear Committee,
>> >>         > >>
>> >>         > >> Zubin Duggal proposes to amend proposal #540, which
>> >>         introduced the -jsem
>> >>         > >> parallelism control mechanism, so that it can avoid
>> >>         incompatibilities
>> >>         > >> arising from different system C library 
>>implementations:
>> >>         > >>
>> >>         > >> 
>>https://github.com/ghc-proposals/ghc-proposals/pull/673
>> >>         <https://github.com/ghc-proposals/ghc-proposals/pull/673>
>> >>         > >>
>> >>         > >>
>> >>         
>>https://github.com/wz1000/ghc-proposals/blob/new-jsem/proposals/0540-jsem.rst 
>><https://github.com/wz1000/ghc-proposals/blob/new-jsem/proposals/0540-jsem.rst>
>> >>         > >>
>> >>         > >> I'd like to nominate Eric Seidel as the shepherd, 
>>since
>> >>         he was the
>> >>         > >> shepherd of the original proposal.
>> >>         > >>
>> >>         > >> Please guide us to a conclusion as outlined in
>> >>         > >>
>> >>         
>>https://github.com/ghc-proposals/ghc-proposals#committee-process 
>><https://github.com/ghc-proposals/ghc-proposals#committee-process>
>> >>         > >>
>> >>         > >> Cheers,
>> >>         > >>
>> >>         > >> Adam
>>
>>
>>--
>>Adam Gundry, Haskell Consultant
>>Well-Typed LLP, https://www.well-typed.com/
>>
>>Registered in England & Wales, OC335890
>>27 Old Gloucester Street, London WC1N 3AX, England
>>
>>_______________________________________________
>>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/20241101/7a22b790/attachment.html>

From malte.ott at maralorn.de  Fri Nov  1 22:22:12 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Fri, 1 Nov 2024 23:22:12 +0100
Subject: [ghc-steering-committee] #668: Allow reserved identifiers as
 fields in OverloadedRecordDot, recommendation: accept
In-Reply-To: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com>
References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com>
Message-ID: <qaecjs532ba2abljgyq4s2swtbhblgtvo5poy7xvcfqdrvdvaj@hera.m-0.eu>


On 2024-10-29 20:12, Adam Gundry wrote:
> https://github.com/ghc-proposals/ghc-proposals/pull/668

I’m in support.

Best
Malte

From mpg at mpg.is  Fri Nov  1 23:27:24 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Sat, 2 Nov 2024 00:27:24 +0100
Subject: [ghc-steering-committee] #668: Allow reserved identifiers as
 fields in OverloadedRecordDot, recommendation: accept
In-Reply-To: <qaecjs532ba2abljgyq4s2swtbhblgtvo5poy7xvcfqdrvdvaj@hera.m-0.eu>
References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com>
 <qaecjs532ba2abljgyq4s2swtbhblgtvo5poy7xvcfqdrvdvaj@hera.m-0.eu>
Message-ID: <CAPxmXQzpxUzhKTySLqbEZ6pUUwbXVHr_RXZV6EB7YSa8hEGcMA@mail.gmail.com>

I’m in support. No need to keep reservations longer than necessary.

/Matti Palli


On Fri, Nov 1, 2024 at 23:22 Malte Ott <malte.ott at maralorn.de> wrote:

>
> On 2024-10-29 20:12, Adam Gundry wrote:
> > https://github.com/ghc-proposals/ghc-proposals/pull/668
>
> I’m in support.
>
> Best
> Malte
> _______________________________________________
> 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/20241102/342fa682/attachment.html>

From erikd at mega-nerd.com  Sat Nov  2 06:28:53 2024
From: erikd at mega-nerd.com (Erik de Castro Lopo)
Date: Sat, 2 Nov 2024 17:28:53 +1100
Subject: [ghc-steering-committee] #668: Allow reserved identifiers as
 fields in OverloadedRecordDot, recommendation: accept
In-Reply-To: <CAPxmXQzpxUzhKTySLqbEZ6pUUwbXVHr_RXZV6EB7YSa8hEGcMA@mail.gmail.com>
References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com>
 <qaecjs532ba2abljgyq4s2swtbhblgtvo5poy7xvcfqdrvdvaj@hera.m-0.eu>
 <CAPxmXQzpxUzhKTySLqbEZ6pUUwbXVHr_RXZV6EB7YSa8hEGcMA@mail.gmail.com>
Message-ID: <20241102172853.d250122548113c86708fb24a@mega-nerd.com>



I am in support.

Erik

Matthías Páll Gissurarson wrote:

> I’m in support. No need to keep reservations longer than necessary.
> 
> /Matti Palli
> 
> 
> On Fri, Nov 1, 2024 at 23:22 Malte Ott <malte.ott at maralorn.de> wrote:
> 
> >
> > On 2024-10-29 20:12, Adam Gundry wrote:
> > > https://github.com/ghc-proposals/ghc-proposals/pull/668
> >
> > I’m in support.
> >
> > Best
> > Malte
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >


-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From sgraf1337 at gmail.com  Sat Nov  2 09:25:04 2024
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Sat, 2 Nov 2024 10:25:04 +0100
Subject: [ghc-steering-committee] #668: Allow reserved identifiers as
 fields in OverloadedRecordDot, recommendation: accept
In-Reply-To: <20241102172853.d250122548113c86708fb24a@mega-nerd.com>
References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com>
 <qaecjs532ba2abljgyq4s2swtbhblgtvo5poy7xvcfqdrvdvaj@hera.m-0.eu>
 <CAPxmXQzpxUzhKTySLqbEZ6pUUwbXVHr_RXZV6EB7YSa8hEGcMA@mail.gmail.com>
 <20241102172853.d250122548113c86708fb24a@mega-nerd.com>
Message-ID: <CAAS+=P_kgA5AoqJx7TCtY4NEj5phVs7cxVx6HVF7XGOZ+6e64w@mail.gmail.com>

I'm in support as well, but would like to see a single clarifying sentence
added to the proposal.
https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003

Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo <
erikd at mega-nerd.com>:

>
>
> I am in support.
>
> Erik
>
> Matthías Páll Gissurarson wrote:
>
> > I’m in support. No need to keep reservations longer than necessary.
> >
> > /Matti Palli
> >
> >
> > On Fri, Nov 1, 2024 at 23:22 Malte Ott <malte.ott at maralorn.de> wrote:
> >
> > >
> > > On 2024-10-29 20:12, Adam Gundry wrote:
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/668
> > >
> > > I’m in support.
> > >
> > > Best
> > > Malte
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >
>
>
> --
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> _______________________________________________
> 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/20241102/0726dded/attachment.html>

From simon.peytonjones at gmail.com  Sat Nov  2 12:20:47 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sat, 2 Nov 2024 12:20:47 +0000
Subject: [ghc-steering-committee] #668: Allow reserved identifiers as
 fields in OverloadedRecordDot, recommendation: accept
In-Reply-To: <CAAS+=P_kgA5AoqJx7TCtY4NEj5phVs7cxVx6HVF7XGOZ+6e64w@mail.gmail.com>
References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com>
 <qaecjs532ba2abljgyq4s2swtbhblgtvo5poy7xvcfqdrvdvaj@hera.m-0.eu>
 <CAPxmXQzpxUzhKTySLqbEZ6pUUwbXVHr_RXZV6EB7YSa8hEGcMA@mail.gmail.com>
 <20241102172853.d250122548113c86708fb24a@mega-nerd.com>
 <CAAS+=P_kgA5AoqJx7TCtY4NEj5phVs7cxVx6HVF7XGOZ+6e64w@mail.gmail.com>
Message-ID: <CAJKmMz8j1SDgT7_z5P6_2NuPYegi2RROG0C+uptWpdDuEpvZTQ@mail.gmail.com>

I'm in support too, but I have made some substantive suggestions on the
GitHub ticket that I'd like to see addressed before we tie a bow on this.

Simon

On Sat, 2 Nov 2024 at 09:25, Sebastian Graf <sgraf1337 at gmail.com> wrote:

> I'm in support as well, but would like to see a single clarifying sentence
> added to the proposal.
>
> https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003
>
> Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo <
> erikd at mega-nerd.com>:
>
>>
>>
>> I am in support.
>>
>> Erik
>>
>> Matthías Páll Gissurarson wrote:
>>
>> > I’m in support. No need to keep reservations longer than necessary.
>> >
>> > /Matti Palli
>> >
>> >
>> > On Fri, Nov 1, 2024 at 23:22 Malte Ott <malte.ott at maralorn.de> wrote:
>> >
>> > >
>> > > On 2024-10-29 20:12, Adam Gundry wrote:
>> > > > https://github.com/ghc-proposals/ghc-proposals/pull/668
>> > >
>> > > I’m in support.
>> > >
>> > > Best
>> > > Malte
>> > > _______________________________________________
>> > > ghc-steering-committee mailing list
>> > > ghc-steering-committee at haskell.org
>> > >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> > >
>>
>>
>> --
>> ----------------------------------------------------------------------
>> Erik de Castro Lopo
>> http://www.mega-nerd.com/
>> _______________________________________________
>> 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/20241102/430aadef/attachment.html>

From arnaud.spiwack at tweag.io  Tue Nov  5 13:58:34 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 5 Nov 2024 22:58:34 +0900
Subject: [ghc-steering-committee] #668: Allow reserved identifiers as
 fields in OverloadedRecordDot, recommendation: accept
In-Reply-To: <CAJKmMz8j1SDgT7_z5P6_2NuPYegi2RROG0C+uptWpdDuEpvZTQ@mail.gmail.com>
References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com>
 <qaecjs532ba2abljgyq4s2swtbhblgtvo5poy7xvcfqdrvdvaj@hera.m-0.eu>
 <CAPxmXQzpxUzhKTySLqbEZ6pUUwbXVHr_RXZV6EB7YSa8hEGcMA@mail.gmail.com>
 <20241102172853.d250122548113c86708fb24a@mega-nerd.com>
 <CAAS+=P_kgA5AoqJx7TCtY4NEj5phVs7cxVx6HVF7XGOZ+6e64w@mail.gmail.com>
 <CAJKmMz8j1SDgT7_z5P6_2NuPYegi2RROG0C+uptWpdDuEpvZTQ@mail.gmail.com>
Message-ID: <CAGwnsnmJKjqgv=PqGbMbFB_72xazSpuYwRXrCqRqLU13NRXKEg@mail.gmail.com>

I have no opinion on this. But I've seen two points in the thread which
make sense: Vlad, our guardian of the parser, says that it's a good idea,
and the comparison with OverloadedLabel (made by Vlad and others) is apt,
and the symmetry is desirable. Ideally the comparison with OverloadedLabel
should be made in the Alternatives section, but I don't feel like insisting
about it :) .

On Sat, 2 Nov 2024 at 21:21, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> I'm in support too, but I have made some substantive suggestions on the
> GitHub ticket that I'd like to see addressed before we tie a bow on this.
>
> Simon
>
> On Sat, 2 Nov 2024 at 09:25, Sebastian Graf <sgraf1337 at gmail.com> wrote:
>
>> I'm in support as well, but would like to see a single clarifying
>> sentence added to the proposal.
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003
>>
>> Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo <
>> erikd at mega-nerd.com>:
>>
>>>
>>>
>>> I am in support.
>>>
>>> Erik
>>>
>>> Matthías Páll Gissurarson wrote:
>>>
>>> > I’m in support. No need to keep reservations longer than necessary.
>>> >
>>> > /Matti Palli
>>> >
>>> >
>>> > On Fri, Nov 1, 2024 at 23:22 Malte Ott <malte.ott at maralorn.de> wrote:
>>> >
>>> > >
>>> > > On 2024-10-29 20:12, Adam Gundry wrote:
>>> > > > https://github.com/ghc-proposals/ghc-proposals/pull/668
>>> > >
>>> > > I’m in support.
>>> > >
>>> > > Best
>>> > > Malte
>>> > > _______________________________________________
>>> > > ghc-steering-committee mailing list
>>> > > ghc-steering-committee at haskell.org
>>> > >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> > >
>>>
>>>
>>> --
>>> ----------------------------------------------------------------------
>>> Erik de Castro Lopo
>>> http://www.mega-nerd.com/
>>> _______________________________________________
>>> 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/20241105/9fac4c0f/attachment.html>

From eric at seidel.io  Sun Nov 10 23:07:22 2024
From: eric at seidel.io (Eric Seidel)
Date: Sun, 10 Nov 2024 17:07:22 -0600
Subject: [ghc-steering-committee] Please review #673: Amendment to -jsem
 proposal #540
In-Reply-To: <emdd6cd63f-b21f-4eb1-9ccd-9d4a43f5cb1d@f217a969.com>
References: <cafec484-0ca7-4f0c-8949-992e9c115537@well-typed.com>
 <20240920100038.f2cc7a353c4b4ce02da189f2@mega-nerd.com>
 <86d15bf6-a4e1-4b5f-bf49-de7f88496f32@app.fastmail.com>
 <i46tbqu3ptd36vlc4sgsckpycry6uzispkp7ksi6i34nfiwoo5@hera.m-0.eu>
 <CAJKmMz8K8twpXOC2uZD8xH006Oi-nt+28q=j+BZkCGW8Ds9zuw@mail.gmail.com>
 <CAGwnsn=nNKX+bh+CWD_dd4N0HTGzBTBnB5oTTKTyp_TNS7_vnA@mail.gmail.com>
 <em63aabb01-6ad6-43e5-b597-afad17fe0a94@ad1f818c.com>
 <c27ff99d-02ab-43ff-b503-4ef3151b8fe5@well-typed.com>
 <CAJKmMz-T=7m=ypVsvXOOjnaBanUfdA2YeknLTZZQTha2d1hFWg@mail.gmail.com>
 <emdd6cd63f-b21f-4eb1-9ccd-9d4a43f5cb1d@f217a969.com>
Message-ID: <c3a741dd-ca26-4664-a2ba-9535341f78c5@app.fastmail.com>

Sorry for my absence folks. I've looked through the updates and think this is basically landing in a good place once the last comments from Sebastian and Simon are addressed.

On Fri, Nov 1, 2024, at 12:00, Sebastian Graf wrote:
> I'm in support as well, but would like to see the relationship to PVP 
> major bumps addressed.
>
>
> ------ Originalnachricht ------
> Von "Simon Peyton Jones" <simon.peytonjones at gmail.com>
> An "Adam Gundry" <adam at well-typed.com>
> Cc ghc-steering-committee at haskell.org
> Datum 29.10.2024 23:16:20
> Betreff Re: [ghc-steering-committee] Please review #673: Amendment to 
> -jsem proposal #540
>
>> I'm supportive.   I do not have a well-informed view, but the amendment is born from practical experience, so I am pretty sure it's an improvement.
>> 
>> I'd love a bit more detail in the proposal (I have commented in one place) but I might be off-target and would yield to others' advice, including that of the author.
>> 
>> Simon
>> 
>> On Tue, 29 Oct 2024 at 19:37, Adam Gundry <adam at well-typed.com> wrote:
>>> It seems Zubin updated the proposal to take account of Sebastian's 
>>> concerns, but then discussion has tailed off. Are we now in a position 
>>> to accept this proposal, or are there any remaining concerns?
>>> 
>>> Cheers,
>>> 
>>> Adam
>>> 
>>> 
>>> 
>>> On 24/09/2024 07:44, Sebastian Graf wrote:
>>> > I think changes to the communication protocol *are* user-facing, in that 
>>> > any change to the protocol could implies a breaking change between all 
>>> > cabal releases in the future and all GHC releases in the past.
>>> > It appears that is the case for the planned release of 
>>> > `semaphore-compat-2`, but I'm not 100% sure.
>>> > 
>>> > In that light, I think it's good to discuss in a proposal to ensure we 
>>> > do not sign off lightly on such breaking changes, in particular for 
>>> > future versions of `semaphore-compat`.
>>> > 
>>> > I will express support once compatibility and breaking changes are 
>>> > properly addressed.
>>> > 
>>> > Sebastian
>>> > 
>>> > ------ Originalnachricht ------
>>> > Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io 
>>> > <mailto:arnaud.spiwack at tweag.io>>
>>> > An "Simon Peyton Jones" <simon.peytonjones at gmail.com 
>>> > <mailto:simon.peytonjones at gmail.com>>
>>> > Cc ghc-steering-committee at haskell.org 
>>> > <mailto:ghc-steering-committee at haskell.org>
>>> > Datum 24.09.2024 04:17:17
>>> > Betreff Re: [ghc-steering-committee] Please review #673: Amendment to 
>>> > -jsem proposal #540
>>> > 
>>> >> Quite frankly, this is barely any user-facing change at all. 
>>> >> Technically the semaphore could previously be shared by non-Haskell 
>>> >> processes in ways the updated proposal doesn't allow. But it's not 
>>> >> really something people do. So it all sounds reasonable.
>>> >>
>>> >> On Mon, 23 Sept 2024 at 19:10, Simon Peyton Jones 
>>> >> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>> >>
>>> >>     I'm happy to support too, but I would like to see presentational
>>> >>     changes, so the final proposal makes sense when read in 5 yrs time.
>>> >>
>>> >>     Simon
>>> >>
>>> >>     On Sat, 21 Sept 2024 at 20:45, Malte Ott <malte.ott at maralorn.de
>>> >>     <mailto:malte.ott at maralorn.de>> wrote:
>>> >>
>>> >>         I agree.
>>> >>
>>> >>         On 2024-09-21 09:16, Eric Seidel wrote:
>>> >>         > Hi all,
>>> >>         >
>>> >>         > This seems like a sensible update to an accepted proposal.
>>> >>         >
>>> >>         > I recommend we accept the amendment.
>>> >>         >
>>> >>         > Eric
>>> >>         >
>>> >>         > On Thu, Sep 19, 2024, at 19:00, Erik de Castro Lopo wrote:
>>> >>         > > Hi all,
>>> >>         > >
>>> >>         > > This is minor updates to correct an existing approved
>>> >>         proposal.
>>> >>         > >
>>> >>         > > I approve of these changes.
>>> >>         > >
>>> >>         > > Erik
>>> >>         > >
>>> >>         > > Adam Gundry wrote:
>>> >>         > >
>>> >>         > >> Dear Committee,
>>> >>         > >>
>>> >>         > >> Zubin Duggal proposes to amend proposal #540, which
>>> >>         introduced the -jsem
>>> >>         > >> parallelism control mechanism, so that it can avoid
>>> >>         incompatibilities
>>> >>         > >> arising from different system C library implementations:
>>> >>         > >>
>>> >>         > >> https://github.com/ghc-proposals/ghc-proposals/pull/673
>>> >>         <https://github.com/ghc-proposals/ghc-proposals/pull/673>
>>> >>         > >>
>>> >>         > >>
>>> >>         https://github.com/wz1000/ghc-proposals/blob/new-jsem/proposals/0540-jsem.rst <https://github.com/wz1000/ghc-proposals/blob/new-jsem/proposals/0540-jsem.rst>
>>> >>         > >>
>>> >>         > >> I'd like to nominate Eric Seidel as the shepherd, since
>>> >>         he was the
>>> >>         > >> shepherd of the original proposal.
>>> >>         > >>
>>> >>         > >> Please guide us to a conclusion as outlined in
>>> >>         > >>
>>> >>         https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>>> >>         > >>
>>> >>         > >> Cheers,
>>> >>         > >>
>>> >>         > >> Adam
>>> 
>>> 
>>> -- 
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>> 
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>> 
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From adam at well-typed.com  Mon Nov 11 08:11:43 2024
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 11 Nov 2024 08:11:43 +0000
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF behavior
 in multiline strings (amendment to #569)
Message-ID: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>

Dear Committee,

Brandon Chinn proposes to amend proposal #569, which introduced 
MultilineStrings, to clarify its treatment of \r\n vs \n:

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

Sebastian has volunteered to act as shepherd.

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

Cheers,

Adam

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

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

From sgraf1337 at gmail.com  Mon Nov 11 08:31:28 2024
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Mon, 11 Nov 2024 08:31:28 +0000
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
Message-ID: <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>

Dear Committee,

I vote accept on this very small clarifying amendment.

Cheers,
Sebastian


------ Originalnachricht ------
Von "Adam Gundry" <adam at well-typed.com>
An ghc-steering-committee at haskell.org
Datum 11.11.2024 09:11:43
Betreff [ghc-steering-committee] Please review #680: Clarify CRLF 
behavior in multiline strings (amendment to #569)

>Dear Committee,
>
>Brandon Chinn proposes to amend proposal #569, which introduced MultilineStrings, to clarify its treatment of \r\n vs \n:
>
>https://github.com/ghc-proposals/ghc-proposals/pull/680
>
>Sebastian has volunteered to act as shepherd.
>
>Please guide us to a conclusion as outlined in
>https://github.com/ghc-proposals/ghc-proposals#committee-process
>
>Cheers,
>
>Adam
>
>-- Adam Gundry, Haskell Consultant
>Well-Typed LLP, https://www.well-typed.com/
>
>Registered in England & Wales, OC335890
>27 Old Gloucester Street, London WC1N 3AX, England
>_______________________________________________
>ghc-steering-committee mailing list
>ghc-steering-committee at haskell.org
>https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From arnaud.spiwack at tweag.io  Mon Nov 11 09:36:29 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 11 Nov 2024 18:36:29 +0900
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
Message-ID: <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>

Sebastian,

As the shepherd you're expected to motivate your decision (typically with a
summary of the proposal) to guide us toward a collective decision.

For the record, in this case, the change is that all characters considered
as `newline` by the report (\r, \n, and a couple others) from the file's
text are replaced by a single `\n` in a multiline string. This isn't what
the current implementation does, if I understand correctly. But GHC 9.12
isn't released, and I think that Brandon considers the current
implementation to be a bug, because his motivation for the design is to
match what `unline . line` does.

I have absolutely no opinion on whether keeping \r\n or converting to \n is
preferable. So I'm happy to defer to Sebastian.

On Mon, 11 Nov 2024 at 17:31, Sebastian Graf <sgraf1337 at gmail.com> wrote:

> Dear Committee,
>
> I vote accept on this very small clarifying amendment.
>
> Cheers,
> Sebastian
>
>
> ------ Originalnachricht ------
> Von "Adam Gundry" <adam at well-typed.com>
> An ghc-steering-committee at haskell.org
> Datum 11.11.2024 09:11:43
> Betreff [ghc-steering-committee] Please review #680: Clarify CRLF
> behavior in multiline strings (amendment to #569)
>
> >Dear Committee,
> >
> >Brandon Chinn proposes to amend proposal #569, which introduced
> MultilineStrings, to clarify its treatment of \r\n vs \n:
> >
> >https://github.com/ghc-proposals/ghc-proposals/pull/680
> >
> >Sebastian has volunteered to act as shepherd.
> >
> >Please guide us to a conclusion as outlined in
> >https://github.com/ghc-proposals/ghc-proposals#committee-process
> >
> >Cheers,
> >
> >Adam
> >
> >-- Adam Gundry, Haskell Consultant
> >Well-Typed LLP, https://www.well-typed.com/
> >
> >Registered in England & Wales, OC335890
> >27 Old Gloucester Street, London WC1N 3AX, England
> >_______________________________________________
> >ghc-steering-committee mailing list
> >ghc-steering-committee at haskell.org
> >https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> 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/20241111/78088458/attachment-0001.html>

From sgraf1337 at gmail.com  Mon Nov 11 09:48:33 2024
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Mon, 11 Nov 2024 09:48:33 +0000
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
 <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
Message-ID: <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>

Hi Arnaud,

Apologies. Indeed, your summary is apt; the proposal is in response to a 
bug report in GHC: https://gitlab.haskell.org/ghc/ghc/-/issues/25375
This bug motivates splitting multiline string literals not only at `\n` 
characters, but at general lexical newline terminators as defined in 
Haskell2010 
<https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2> 
(which would also include `\r\n`, `\r` and `\f`).
The phrasing in the proposal pre amendment can be seen as ambiguous: 
What exactly is considered a "newline"? Is it just `\n` or is it the 
`newline` lexeme specified in Haskell2010 and that is used anywhere else 
in the report?
The amendment merely clarifies that we mean the latter.

This amendment also resolves the question of whether there is a bug in 
the yet unreleased implementation of -XMultilineStrings in GHC 9.12 or 
in the proposal text. After this amendment, the bug is in GHC, where it 
is easily fixed 
(https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432).

Hence I recommend acceptance.

Cheers,
Sebastian


------ Originalnachricht ------
Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io>
An "Sebastian Graf" <sgraf1337 at gmail.com>
Cc "Adam Gundry" <adam at well-typed.com>; 
ghc-steering-committee at haskell.org
Datum 11.11.2024 10:36:29
Betreff Re: [ghc-steering-committee] Please review #680: Clarify CRLF 
behavior in multiline strings (amendment to #569)

>Sebastian,
>
>As the shepherd you're expected to motivate your decision (typically 
>with a summary of the proposal) to guide us toward a collective 
>decision.
>
>For the record, in this case, the change is that all characters 
>considered as `newline` by the report (\r, \n, and a couple others) 
>from the file's text are replaced by a single `\n` in a multiline 
>string. This isn't what the current implementation does, if I 
>understand correctly. But GHC 9.12 isn't released, and I think that 
>Brandon considers the current implementation to be a bug, because his 
>motivation for the design is to match what `unline . line` does.
>
>I have absolutely no opinion on whether keeping \r\n or converting to 
>\n is preferable. So I'm happy to defer to Sebastian.
>
>On Mon, 11 Nov 2024 at 17:31, Sebastian Graf <sgraf1337 at gmail.com> 
>wrote:
>>Dear Committee,
>>
>>I vote accept on this very small clarifying amendment.
>>
>>Cheers,
>>Sebastian
>>
>>
>>------ Originalnachricht ------
>>Von "Adam Gundry" <adam at well-typed.com>
>>An ghc-steering-committee at haskell.org
>>Datum 11.11.2024 09:11:43
>>Betreff [ghc-steering-committee] Please review #680: Clarify CRLF
>>behavior in multiline strings (amendment to #569)
>>
>> >Dear Committee,
>> >
>> >Brandon Chinn proposes to amend proposal #569, which introduced 
>>MultilineStrings, to clarify its treatment of \r\n vs \n:
>> >
>> >https://github.com/ghc-proposals/ghc-proposals/pull/680
>> >
>> >Sebastian has volunteered to act as shepherd.
>> >
>> >Please guide us to a conclusion as outlined in
>> >https://github.com/ghc-proposals/ghc-proposals#committee-process
>> >
>> >Cheers,
>> >
>> >Adam
>> >
>> >-- Adam Gundry, Haskell Consultant
>> >Well-Typed LLP, https://www.well-typed.com/
>> >
>> >Registered in England & Wales, OC335890
>> >27 Old Gloucester Street, London WC1N 3AX, England
>> >_______________________________________________
>> >ghc-steering-committee mailing list
>> >ghc-steering-committee at haskell.org
>> >https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>_______________________________________________
>>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/20241111/9be84172/attachment.html>

From simon.peytonjones at gmail.com  Mon Nov 11 22:41:57 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 11 Nov 2024 22:41:57 +0000
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
 <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
 <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>
Message-ID: <CAJKmMz90srtSEex56eQ6FDfrjDMVdqZoKyo8ZGycAkcXiBuO6g@mail.gmail.com>

Looks fine to me. I support.

Simon

On Mon, 11 Nov 2024 at 09:48, Sebastian Graf <sgraf1337 at gmail.com> wrote:

> Hi Arnaud,
>
> Apologies. Indeed, your summary is apt; the proposal is in response to a
> bug report in GHC: https://gitlab.haskell.org/ghc/ghc/-/issues/25375
> This bug motivates splitting multiline string literals not only at `\n`
> characters, but at general lexical newline terminators as defined in
> Haskell2010
> <https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2>
> (which would also include `\r\n`, `\r` and `\f`).
> The phrasing in the proposal pre amendment can be seen as ambiguous: What
> exactly is considered a "newline"? Is it just `\n` or is it the `newline`
> lexeme specified in Haskell2010 and that is used anywhere else in the
> report?
> The amendment merely clarifies that we mean the latter.
>
> This amendment also resolves the question of whether there is a bug in the
> yet unreleased implementation of -XMultilineStrings in GHC 9.12 or in the
> proposal text. After this amendment, the bug is in GHC, where it is easily
> fixed (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432).
>
> Hence I recommend acceptance.
>
> Cheers,
> Sebastian
>
>
> ------ Originalnachricht ------
> Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io>
> An "Sebastian Graf" <sgraf1337 at gmail.com>
> Cc "Adam Gundry" <adam at well-typed.com>; ghc-steering-committee at haskell.org
> Datum 11.11.2024 10:36:29
> Betreff Re: [ghc-steering-committee] Please review #680: Clarify CRLF
> behavior in multiline strings (amendment to #569)
>
> Sebastian,
>
> As the shepherd you're expected to motivate your decision (typically with
> a summary of the proposal) to guide us toward a collective decision.
>
> For the record, in this case, the change is that all characters considered
> as `newline` by the report (\r, \n, and a couple others) from the file's
> text are replaced by a single `\n` in a multiline string. This isn't what
> the current implementation does, if I understand correctly. But GHC 9.12
> isn't released, and I think that Brandon considers the current
> implementation to be a bug, because his motivation for the design is to
> match what `unline . line` does.
>
> I have absolutely no opinion on whether keeping \r\n or converting to \n
> is preferable. So I'm happy to defer to Sebastian.
>
> On Mon, 11 Nov 2024 at 17:31, Sebastian Graf <sgraf1337 at gmail.com> wrote:
>
>> Dear Committee,
>>
>> I vote accept on this very small clarifying amendment.
>>
>> Cheers,
>> Sebastian
>>
>>
>> ------ Originalnachricht ------
>> Von "Adam Gundry" <adam at well-typed.com>
>> An ghc-steering-committee at haskell.org
>> Datum 11.11.2024 09:11:43
>> Betreff [ghc-steering-committee] Please review #680: Clarify CRLF
>> behavior in multiline strings (amendment to #569)
>>
>> >Dear Committee,
>> >
>> >Brandon Chinn proposes to amend proposal #569, which introduced
>> MultilineStrings, to clarify its treatment of \r\n vs \n:
>> >
>> >https://github.com/ghc-proposals/ghc-proposals/pull/680
>> >
>> >Sebastian has volunteered to act as shepherd.
>> >
>> >Please guide us to a conclusion as outlined in
>> >https://github.com/ghc-proposals/ghc-proposals#committee-process
>> >
>> >Cheers,
>> >
>> >Adam
>> >
>> >-- Adam Gundry, Haskell Consultant
>> >Well-Typed LLP, https://www.well-typed.com/
>> >
>> >Registered in England & Wales, OC335890
>> >27 Old Gloucester Street, London WC1N 3AX, England
>> >_______________________________________________
>> >ghc-steering-committee mailing list
>> >ghc-steering-committee at haskell.org
>> >https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20241111/d72b43da/attachment.html>

From moritz.angermann at gmail.com  Tue Nov 12 06:01:37 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 12 Nov 2024 15:01:37 +0900
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <CAJKmMz90srtSEex56eQ6FDfrjDMVdqZoKyo8ZGycAkcXiBuO6g@mail.gmail.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
 <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
 <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>
 <CAJKmMz90srtSEex56eQ6FDfrjDMVdqZoKyo8ZGycAkcXiBuO6g@mail.gmail.com>
Message-ID: <CAKfdd-xf-ZvG4Srp_fk4LSfhi_Z=XNTy9ZCGuRpqf1Dqoad9tg@mail.gmail.com>

I’m in support. I see the \r and \r\n as opposed to \n as legacy. There of
course is a problem cross-system. I just hope this will never bite us.

On Tue, Nov 12, 2024 at 7:42 AM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Looks fine to me. I support.
>
> Simon
>
> On Mon, 11 Nov 2024 at 09:48, Sebastian Graf <sgraf1337 at gmail.com> wrote:
>
>> Hi Arnaud,
>>
>> Apologies. Indeed, your summary is apt; the proposal is in response to a
>> bug report in GHC: https://gitlab.haskell.org/ghc/ghc/-/issues/25375
>> This bug motivates splitting multiline string literals not only at `\n`
>> characters, but at general lexical newline terminators as defined in
>> Haskell2010
>> <https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2>
>> (which would also include `\r\n`, `\r` and `\f`).
>> The phrasing in the proposal pre amendment can be seen as ambiguous: What
>> exactly is considered a "newline"? Is it just `\n` or is it the `newline`
>> lexeme specified in Haskell2010 and that is used anywhere else in the
>> report?
>> The amendment merely clarifies that we mean the latter.
>>
>> This amendment also resolves the question of whether there is a bug in the
>> yet unreleased implementation of -XMultilineStrings in GHC 9.12 or in the
>> proposal text. After this amendment, the bug is in GHC, where it is easily
>> fixed (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432).
>>
>> Hence I recommend acceptance.
>>
>> Cheers,
>> Sebastian
>>
>>
>> ------ Originalnachricht ------
>> Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io>
>> An "Sebastian Graf" <sgraf1337 at gmail.com>
>> Cc "Adam Gundry" <adam at well-typed.com>;
>> ghc-steering-committee at haskell.org
>> Datum 11.11.2024 10:36:29
>> Betreff Re: [ghc-steering-committee] Please review #680: Clarify CRLF
>> behavior in multiline strings (amendment to #569)
>>
>> Sebastian,
>>
>> As the shepherd you're expected to motivate your decision (typically with
>> a summary of the proposal) to guide us toward a collective decision.
>>
>> For the record, in this case, the change is that all characters
>> considered as `newline` by the report (\r, \n, and a couple others) from
>> the file's text are replaced by a single `\n` in a multiline string. This
>> isn't what the current implementation does, if I understand correctly. But
>> GHC 9.12 isn't released, and I think that Brandon considers the current
>> implementation to be a bug, because his motivation for the design is to
>> match what `unline . line` does.
>>
>> I have absolutely no opinion on whether keeping \r\n or converting to \n
>> is preferable. So I'm happy to defer to Sebastian.
>>
>> On Mon, 11 Nov 2024 at 17:31, Sebastian Graf <sgraf1337 at gmail.com> wrote:
>>
>>> Dear Committee,
>>>
>>> I vote accept on this very small clarifying amendment.
>>>
>>> Cheers,
>>> Sebastian
>>>
>>>
>>> ------ Originalnachricht ------
>>> Von "Adam Gundry" <adam at well-typed.com>
>>> An ghc-steering-committee at haskell.org
>>> Datum 11.11.2024 09:11:43
>>> Betreff [ghc-steering-committee] Please review #680: Clarify CRLF
>>> behavior in multiline strings (amendment to #569)
>>>
>>> >Dear Committee,
>>> >
>>> >Brandon Chinn proposes to amend proposal #569, which introduced
>>> MultilineStrings, to clarify its treatment of \r\n vs \n:
>>> >
>>> >https://github.com/ghc-proposals/ghc-proposals/pull/680
>>> >
>>> >Sebastian has volunteered to act as shepherd.
>>> >
>>> >Please guide us to a conclusion as outlined in
>>> >https://github.com/ghc-proposals/ghc-proposals#committee-process
>>> >
>>> >Cheers,
>>> >
>>> >Adam
>>> >
>>> >-- Adam Gundry, Haskell Consultant
>>> >Well-Typed LLP, https://www.well-typed.com/
>>> >
>>> >Registered in England & Wales, OC335890
>>> >27 Old Gloucester Street, London WC1N 3AX, England
>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>> >_______________________________________________
>>> >ghc-steering-committee mailing list
>>> >ghc-steering-committee at haskell.org
>>> >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20241112/81565b73/attachment-0001.html>

From jakob.bruenker at gmail.com  Tue Nov 12 20:58:09 2024
From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=)
Date: Tue, 12 Nov 2024 21:58:09 +0100
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <CAKfdd-xf-ZvG4Srp_fk4LSfhi_Z=XNTy9ZCGuRpqf1Dqoad9tg@mail.gmail.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
 <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
 <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>
 <CAJKmMz90srtSEex56eQ6FDfrjDMVdqZoKyo8ZGycAkcXiBuO6g@mail.gmail.com>
 <CAKfdd-xf-ZvG4Srp_fk4LSfhi_Z=XNTy9ZCGuRpqf1Dqoad9tg@mail.gmail.com>
Message-ID: <CAJjQ6oNoVLvPjBkRjyT=_Ajs8ypFubAGtYV_0jP9UsW=u_v6Ng@mail.gmail.com>

I'm in support. Not matching the behavior of unlines would be odd.

On Tue, Nov 12, 2024 at 7:02 AM Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> I’m in support. I see the \r and \r\n as opposed to \n as legacy. There of
> course is a problem cross-system. I just hope this will never bite us.
>
> On Tue, Nov 12, 2024 at 7:42 AM Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Looks fine to me. I support.
>>
>> Simon
>>
>> On Mon, 11 Nov 2024 at 09:48, Sebastian Graf <sgraf1337 at gmail.com> wrote:
>>
>>> Hi Arnaud,
>>>
>>> Apologies. Indeed, your summary is apt; the proposal is in response to a
>>> bug report in GHC: https://gitlab.haskell.org/ghc/ghc/-/issues/25375
>>> This bug motivates splitting multiline string literals not only at `\n`
>>> characters, but at general lexical newline terminators as defined in
>>> Haskell2010
>>> <https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2>
>>> (which would also include `\r\n`, `\r` and `\f`).
>>> The phrasing in the proposal pre amendment can be seen as ambiguous:
>>> What exactly is considered a "newline"? Is it just `\n` or is it the
>>> `newline` lexeme specified in Haskell2010 and that is used anywhere else in
>>> the report?
>>> The amendment merely clarifies that we mean the latter.
>>>
>>> This amendment also resolves the question of whether there is a bug in the
>>> yet unreleased implementation of -XMultilineStrings in GHC 9.12 or in the
>>> proposal text. After this amendment, the bug is in GHC, where it is easily
>>> fixed (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432).
>>>
>>> Hence I recommend acceptance.
>>>
>>> Cheers,
>>> Sebastian
>>>
>>>
>>> ------ Originalnachricht ------
>>> Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io>
>>> An "Sebastian Graf" <sgraf1337 at gmail.com>
>>> Cc "Adam Gundry" <adam at well-typed.com>;
>>> ghc-steering-committee at haskell.org
>>> Datum 11.11.2024 10:36:29
>>> Betreff Re: [ghc-steering-committee] Please review #680: Clarify CRLF
>>> behavior in multiline strings (amendment to #569)
>>>
>>> Sebastian,
>>>
>>> As the shepherd you're expected to motivate your decision (typically
>>> with a summary of the proposal) to guide us toward a collective decision.
>>>
>>> For the record, in this case, the change is that all characters
>>> considered as `newline` by the report (\r, \n, and a couple others) from
>>> the file's text are replaced by a single `\n` in a multiline string. This
>>> isn't what the current implementation does, if I understand correctly. But
>>> GHC 9.12 isn't released, and I think that Brandon considers the current
>>> implementation to be a bug, because his motivation for the design is to
>>> match what `unline . line` does.
>>>
>>> I have absolutely no opinion on whether keeping \r\n or converting to \n
>>> is preferable. So I'm happy to defer to Sebastian.
>>>
>>> On Mon, 11 Nov 2024 at 17:31, Sebastian Graf <sgraf1337 at gmail.com>
>>> wrote:
>>>
>>>> Dear Committee,
>>>>
>>>> I vote accept on this very small clarifying amendment.
>>>>
>>>> Cheers,
>>>> Sebastian
>>>>
>>>>
>>>> ------ Originalnachricht ------
>>>> Von "Adam Gundry" <adam at well-typed.com>
>>>> An ghc-steering-committee at haskell.org
>>>> Datum 11.11.2024 09:11:43
>>>> Betreff [ghc-steering-committee] Please review #680: Clarify CRLF
>>>> behavior in multiline strings (amendment to #569)
>>>>
>>>> >Dear Committee,
>>>> >
>>>> >Brandon Chinn proposes to amend proposal #569, which introduced
>>>> MultilineStrings, to clarify its treatment of \r\n vs \n:
>>>> >
>>>> >https://github.com/ghc-proposals/ghc-proposals/pull/680
>>>> >
>>>> >Sebastian has volunteered to act as shepherd.
>>>> >
>>>> >Please guide us to a conclusion as outlined in
>>>> >https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>> >
>>>> >Cheers,
>>>> >
>>>> >Adam
>>>> >
>>>> >-- Adam Gundry, Haskell Consultant
>>>> >Well-Typed LLP, https://www.well-typed.com/
>>>> >
>>>> >Registered in England & Wales, OC335890
>>>> >27 Old Gloucester Street, London WC1N 3AX, England
>>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>> >_______________________________________________
>>>> >ghc-steering-committee mailing list
>>>> >ghc-steering-committee at haskell.org
>>>> >
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> 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/20241112/28d27140/attachment.html>

From adam at well-typed.com  Tue Nov 12 20:58:53 2024
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 12 Nov 2024 20:58:53 +0000
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <CAKfdd-xf-ZvG4Srp_fk4LSfhi_Z=XNTy9ZCGuRpqf1Dqoad9tg@mail.gmail.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
 <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
 <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>
 <CAJKmMz90srtSEex56eQ6FDfrjDMVdqZoKyo8ZGycAkcXiBuO6g@mail.gmail.com>
 <CAKfdd-xf-ZvG4Srp_fk4LSfhi_Z=XNTy9ZCGuRpqf1Dqoad9tg@mail.gmail.com>
Message-ID: <e4e208d9-f765-448d-b5da-985d62d077fa@well-typed.com>

I'm happy to support this. Let's get it done for 9.12 so we don't have 
an inconsistency across versions.

Adam


On 12/11/2024 06:01, Moritz Angermann wrote:
> I’m in support. I see the \r and \r\n as opposed to \n as legacy. There 
> of course is a problem cross-system. I just hope this will never bite us.
> 
> On Tue, Nov 12, 2024 at 7:42 AM Simon Peyton Jones 
> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>     Looks fine to me. I support.
> 
>     Simon
> 
>     On Mon, 11 Nov 2024 at 09:48, Sebastian Graf <sgraf1337 at gmail.com
>     <mailto:sgraf1337 at gmail.com>> wrote:
> 
>         Hi Arnaud,
> 
>         Apologies. Indeed, your summary is apt; the proposal is in
>         response to a bug report in GHC:
>         https://gitlab.haskell.org/ghc/ghc/-/issues/25375
>         <https://gitlab.haskell.org/ghc/ghc/-/issues/25375>
>         This bug motivates splitting multiline string literals not only
>         at `\n` characters, but at general lexical newline terminators
>         as defined in Haskell2010
>         <https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2> (which would also include `\r\n`, `\r` and `\f`).
>         The phrasing in the proposal pre amendment can be seen as
>         ambiguous: What exactly is considered a "newline"? Is it just
>         `\n` or is it the `newline` lexeme specified in Haskell2010 and
>         that is used anywhere else in the report?
>         The amendment merely clarifies that we mean the latter.
> 
>         This amendment also resolves the question of whether there is a
>         bug in the yet unreleased implementation of -XMultilineStrings
>         in GHC 9.12 or in the proposal text. After this amendment, the
>         bug is in GHC, where it is easily fixed
>         (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432
>         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432>).
> 
>         Hence I recommend acceptance.
> 
>         Cheers,
>         Sebastian
> 
> 
>         ------ Originalnachricht ------
>         Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io
>         <mailto:arnaud.spiwack at tweag.io>>
>         An "Sebastian Graf" <sgraf1337 at gmail.com
>         <mailto:sgraf1337 at gmail.com>>
>         Cc "Adam Gundry" <adam at well-typed.com
>         <mailto:adam at well-typed.com>>;
>         ghc-steering-committee at haskell.org
>         <mailto:ghc-steering-committee at haskell.org>
>         Datum 11.11.2024 10:36:29
>         Betreff Re: [ghc-steering-committee] Please review #680: Clarify
>         CRLF behavior in multiline strings (amendment to #569)
> 
>>         Sebastian,
>>
>>         As the shepherd you're expected to motivate your decision
>>         (typically with a summary of the proposal) to guide us toward
>>         a collective decision.
>>
>>         For the record, in this case, the change is that all
>>         characters considered as `newline` by the report (\r, \n, and
>>         a couple others) from the file's text are replaced by a single
>>         `\n` in a multiline string. This isn't what the current
>>         implementation does, if I understand correctly. But GHC 9.12
>>         isn't released, and I think that Brandon considers the current
>>         implementation to be a bug, because his motivation for the
>>         design is to match what `unline . line` does.
>>
>>         I have absolutely no opinion on whether keeping \r\n or
>>         converting to \n is preferable. So I'm happy to defer to
>>         Sebastian.
>>
>>         On Mon, 11 Nov 2024 at 17:31, Sebastian Graf
>>         <sgraf1337 at gmail.com <mailto:sgraf1337 at gmail.com>> wrote:
>>
>>             Dear Committee,
>>
>>             I vote accept on this very small clarifying amendment.
>>
>>             Cheers,
>>             Sebastian
>>
>>
>>             ------ Originalnachricht ------
>>             Von "Adam Gundry" <adam at well-typed.com
>>             <mailto:adam at well-typed.com>>
>>             An ghc-steering-committee at haskell.org
>>             <mailto:ghc-steering-committee at haskell.org>
>>             Datum 11.11.2024 09:11:43
>>             Betreff [ghc-steering-committee] Please review #680:
>>             Clarify CRLF
>>             behavior in multiline strings (amendment to #569)
>>
>>             >Dear Committee,
>>             >
>>             >Brandon Chinn proposes to amend proposal #569, which
>>             introduced MultilineStrings, to clarify its treatment of
>>             \r\n vs \n:
>>             >
>>             >https://github.com/ghc-proposals/ghc-proposals/pull/680
>>             <https://github.com/ghc-proposals/ghc-proposals/pull/680>
>>             >
>>             >Sebastian has volunteered to act as shepherd.
>>             >
>>             >Please guide us to a conclusion as outlined in
>>             >https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>>             >
>>             >Cheers,
>>             >
>>             >Adam
>>             >
>>             >-- Adam Gundry, Haskell Consultant
>>             >Well-Typed LLP, https://www.well-typed.com/
>>             <https://www.well-typed.com/>
>>             >
>>             >Registered in England & Wales, OC335890
>>             >27 Old Gloucester Street, London WC1N 3AX, England
>>             <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>             >_______________________________________________
>>             >ghc-steering-committee mailing list
>>             >ghc-steering-committee at haskell.org
>>             <mailto:ghc-steering-committee at haskell.org>
>>             >https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>>             _______________________________________________
>>             ghc-steering-committee mailing list
>>             ghc-steering-committee at haskell.org
>>             <mailto:ghc-steering-committee at haskell.org>
>>             https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>>
>>
>>
>>         -- 
>>         Arnaud Spiwack
>>         Director, Research at https://moduscreate.com
>>         <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
>         _______________________________________________
>         ghc-steering-committee mailing list
>         ghc-steering-committee at haskell.org
>         <mailto:ghc-steering-committee at haskell.org>
>         https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
>     _______________________________________________
>     ghc-steering-committee mailing list
>     ghc-steering-committee at haskell.org
>     <mailto:ghc-steering-committee at haskell.org>
>     https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- 
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 malte.ott at maralorn.de  Tue Nov 12 22:28:14 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Tue, 12 Nov 2024 23:28:14 +0100
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <e4e208d9-f765-448d-b5da-985d62d077fa@well-typed.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
 <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
 <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>
 <CAJKmMz90srtSEex56eQ6FDfrjDMVdqZoKyo8ZGycAkcXiBuO6g@mail.gmail.com>
 <CAKfdd-xf-ZvG4Srp_fk4LSfhi_Z=XNTy9ZCGuRpqf1Dqoad9tg@mail.gmail.com>
 <e4e208d9-f765-448d-b5da-985d62d077fa@well-typed.com>
Message-ID: <m4tjckl7cyzyahwb5uw6jm3taj2c2b3tar45tbemrrvzu6hpeg@hera.m-0.eu>

I agree.

On 2024-11-12 20:58, Adam Gundry wrote:
> I'm happy to support this. Let's get it done for 9.12 so we don't have an
> inconsistency across versions.
> 
> Adam
> 
> 
> On 12/11/2024 06:01, Moritz Angermann wrote:
> > I’m in support. I see the \r and \r\n as opposed to \n as legacy. There
> > of course is a problem cross-system. I just hope this will never bite
> > us.
> > 
> > On Tue, Nov 12, 2024 at 7:42 AM Simon Peyton Jones
> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> > wrote:
> > 
> >     Looks fine to me. I support.
> > 
> >     Simon
> > 
> >     On Mon, 11 Nov 2024 at 09:48, Sebastian Graf <sgraf1337 at gmail.com
> >     <mailto:sgraf1337 at gmail.com>> wrote:
> > 
> >         Hi Arnaud,
> > 
> >         Apologies. Indeed, your summary is apt; the proposal is in
> >         response to a bug report in GHC:
> >         https://gitlab.haskell.org/ghc/ghc/-/issues/25375
> >         <https://gitlab.haskell.org/ghc/ghc/-/issues/25375>
> >         This bug motivates splitting multiline string literals not only
> >         at `\n` characters, but at general lexical newline terminators
> >         as defined in Haskell2010
> >         <https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2> (which would also include `\r\n`, `\r` and `\f`).
> >         The phrasing in the proposal pre amendment can be seen as
> >         ambiguous: What exactly is considered a "newline"? Is it just
> >         `\n` or is it the `newline` lexeme specified in Haskell2010 and
> >         that is used anywhere else in the report?
> >         The amendment merely clarifies that we mean the latter.
> > 
> >         This amendment also resolves the question of whether there is a
> >         bug in the yet unreleased implementation of -XMultilineStrings
> >         in GHC 9.12 or in the proposal text. After this amendment, the
> >         bug is in GHC, where it is easily fixed
> >         (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432
> >         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432>).
> > 
> >         Hence I recommend acceptance.
> > 
> >         Cheers,
> >         Sebastian
> > 
> > 
> >         ------ Originalnachricht ------
> >         Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io
> >         <mailto:arnaud.spiwack at tweag.io>>
> >         An "Sebastian Graf" <sgraf1337 at gmail.com
> >         <mailto:sgraf1337 at gmail.com>>
> >         Cc "Adam Gundry" <adam at well-typed.com
> >         <mailto:adam at well-typed.com>>;
> >         ghc-steering-committee at haskell.org
> >         <mailto:ghc-steering-committee at haskell.org>
> >         Datum 11.11.2024 10:36:29
> >         Betreff Re: [ghc-steering-committee] Please review #680: Clarify
> >         CRLF behavior in multiline strings (amendment to #569)
> > 
> > >         Sebastian,
> > > 
> > >         As the shepherd you're expected to motivate your decision
> > >         (typically with a summary of the proposal) to guide us toward
> > >         a collective decision.
> > > 
> > >         For the record, in this case, the change is that all
> > >         characters considered as `newline` by the report (\r, \n, and
> > >         a couple others) from the file's text are replaced by a single
> > >         `\n` in a multiline string. This isn't what the current
> > >         implementation does, if I understand correctly. But GHC 9.12
> > >         isn't released, and I think that Brandon considers the current
> > >         implementation to be a bug, because his motivation for the
> > >         design is to match what `unline . line` does.
> > > 
> > >         I have absolutely no opinion on whether keeping \r\n or
> > >         converting to \n is preferable. So I'm happy to defer to
> > >         Sebastian.
> > > 
> > >         On Mon, 11 Nov 2024 at 17:31, Sebastian Graf
> > >         <sgraf1337 at gmail.com <mailto:sgraf1337 at gmail.com>> wrote:
> > > 
> > >             Dear Committee,
> > > 
> > >             I vote accept on this very small clarifying amendment.
> > > 
> > >             Cheers,
> > >             Sebastian
> > > 
> > > 
> > >             ------ Originalnachricht ------
> > >             Von "Adam Gundry" <adam at well-typed.com
> > >             <mailto:adam at well-typed.com>>
> > >             An ghc-steering-committee at haskell.org
> > >             <mailto:ghc-steering-committee at haskell.org>
> > >             Datum 11.11.2024 09:11:43
> > >             Betreff [ghc-steering-committee] Please review #680:
> > >             Clarify CRLF
> > >             behavior in multiline strings (amendment to #569)
> > > 
> > >             >Dear Committee,
> > >             >
> > >             >Brandon Chinn proposes to amend proposal #569, which
> > >             introduced MultilineStrings, to clarify its treatment of
> > >             \r\n vs \n:
> > >             >
> > >             >https://github.com/ghc-proposals/ghc-proposals/pull/680
> > >             <https://github.com/ghc-proposals/ghc-proposals/pull/680>
> > >             >
> > >             >Sebastian has volunteered to act as shepherd.
> > >             >
> > >             >Please guide us to a conclusion as outlined in
> > >             >https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> > >             >
> > >             >Cheers,
> > >             >
> > >             >Adam
> > >             >
> > >             >-- Adam Gundry, Haskell Consultant
> > >             >Well-Typed LLP, https://www.well-typed.com/
> > >             <https://www.well-typed.com/>
> > >             >
> > >             >Registered in England & Wales, OC335890
> > >             >27 Old Gloucester Street, London WC1N 3AX, England
> > >             <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
> > >             >_______________________________________________
> > >             >ghc-steering-committee mailing list
> > >             >ghc-steering-committee at haskell.org
> > >             <mailto:ghc-steering-committee at haskell.org>
> > >             >https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> > >             _______________________________________________
> > >             ghc-steering-committee mailing list
> > >             ghc-steering-committee at haskell.org
> > >             <mailto:ghc-steering-committee at haskell.org>
> > >             https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> > > 
> > > 
> > > 
> > >         --         Arnaud Spiwack
> > >         Director, Research at https://moduscreate.com
> > >         <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
> >         _______________________________________________
> >         ghc-steering-committee mailing list
> >         ghc-steering-committee at haskell.org
> >         <mailto:ghc-steering-committee at haskell.org>
> >         https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> > 
> >     _______________________________________________
> >     ghc-steering-committee mailing list
> >     ghc-steering-committee at haskell.org
> >     <mailto:ghc-steering-committee at haskell.org>
> >     https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> > 
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> -- 
> 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 eric at seidel.io  Sun Nov 17 16:26:37 2024
From: eric at seidel.io (Eric Seidel)
Date: Sun, 17 Nov 2024 10:26:37 -0600
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <m4tjckl7cyzyahwb5uw6jm3taj2c2b3tar45tbemrrvzu6hpeg@hera.m-0.eu>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
 <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
 <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>
 <CAJKmMz90srtSEex56eQ6FDfrjDMVdqZoKyo8ZGycAkcXiBuO6g@mail.gmail.com>
 <CAKfdd-xf-ZvG4Srp_fk4LSfhi_Z=XNTy9ZCGuRpqf1Dqoad9tg@mail.gmail.com>
 <e4e208d9-f765-448d-b5da-985d62d077fa@well-typed.com>
 <m4tjckl7cyzyahwb5uw6jm3taj2c2b3tar45tbemrrvzu6hpeg@hera.m-0.eu>
Message-ID: <ff6db4dc-377e-4498-b065-85436ec8df06@app.fastmail.com>

Makes sense, the clarification is what I would have expected.

On Tue, Nov 12, 2024, at 16:28, Malte Ott wrote:
> I agree.
>
> On 2024-11-12 20:58, Adam Gundry wrote:
>> I'm happy to support this. Let's get it done for 9.12 so we don't have an
>> inconsistency across versions.
>> 
>> Adam
>> 
>> 
>> On 12/11/2024 06:01, Moritz Angermann wrote:
>> > I’m in support. I see the \r and \r\n as opposed to \n as legacy. There
>> > of course is a problem cross-system. I just hope this will never bite
>> > us.
>> > 
>> > On Tue, Nov 12, 2024 at 7:42 AM Simon Peyton Jones
>> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>> > wrote:
>> > 
>> >     Looks fine to me. I support.
>> > 
>> >     Simon
>> > 
>> >     On Mon, 11 Nov 2024 at 09:48, Sebastian Graf <sgraf1337 at gmail.com
>> >     <mailto:sgraf1337 at gmail.com>> wrote:
>> > 
>> >         Hi Arnaud,
>> > 
>> >         Apologies. Indeed, your summary is apt; the proposal is in
>> >         response to a bug report in GHC:
>> >         https://gitlab.haskell.org/ghc/ghc/-/issues/25375
>> >         <https://gitlab.haskell.org/ghc/ghc/-/issues/25375>
>> >         This bug motivates splitting multiline string literals not only
>> >         at `\n` characters, but at general lexical newline terminators
>> >         as defined in Haskell2010
>> >         <https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2> (which would also include `\r\n`, `\r` and `\f`).
>> >         The phrasing in the proposal pre amendment can be seen as
>> >         ambiguous: What exactly is considered a "newline"? Is it just
>> >         `\n` or is it the `newline` lexeme specified in Haskell2010 and
>> >         that is used anywhere else in the report?
>> >         The amendment merely clarifies that we mean the latter.
>> > 
>> >         This amendment also resolves the question of whether there is a
>> >         bug in the yet unreleased implementation of -XMultilineStrings
>> >         in GHC 9.12 or in the proposal text. After this amendment, the
>> >         bug is in GHC, where it is easily fixed
>> >         (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432
>> >         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432>).
>> > 
>> >         Hence I recommend acceptance.
>> > 
>> >         Cheers,
>> >         Sebastian
>> > 
>> > 
>> >         ------ Originalnachricht ------
>> >         Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io
>> >         <mailto:arnaud.spiwack at tweag.io>>
>> >         An "Sebastian Graf" <sgraf1337 at gmail.com
>> >         <mailto:sgraf1337 at gmail.com>>
>> >         Cc "Adam Gundry" <adam at well-typed.com
>> >         <mailto:adam at well-typed.com>>;
>> >         ghc-steering-committee at haskell.org
>> >         <mailto:ghc-steering-committee at haskell.org>
>> >         Datum 11.11.2024 10:36:29
>> >         Betreff Re: [ghc-steering-committee] Please review #680: Clarify
>> >         CRLF behavior in multiline strings (amendment to #569)
>> > 
>> > >         Sebastian,
>> > > 
>> > >         As the shepherd you're expected to motivate your decision
>> > >         (typically with a summary of the proposal) to guide us toward
>> > >         a collective decision.
>> > > 
>> > >         For the record, in this case, the change is that all
>> > >         characters considered as `newline` by the report (\r, \n, and
>> > >         a couple others) from the file's text are replaced by a single
>> > >         `\n` in a multiline string. This isn't what the current
>> > >         implementation does, if I understand correctly. But GHC 9.12
>> > >         isn't released, and I think that Brandon considers the current
>> > >         implementation to be a bug, because his motivation for the
>> > >         design is to match what `unline . line` does.
>> > > 
>> > >         I have absolutely no opinion on whether keeping \r\n or
>> > >         converting to \n is preferable. So I'm happy to defer to
>> > >         Sebastian.
>> > > 
>> > >         On Mon, 11 Nov 2024 at 17:31, Sebastian Graf
>> > >         <sgraf1337 at gmail.com <mailto:sgraf1337 at gmail.com>> wrote:
>> > > 
>> > >             Dear Committee,
>> > > 
>> > >             I vote accept on this very small clarifying amendment.
>> > > 
>> > >             Cheers,
>> > >             Sebastian
>> > > 
>> > > 
>> > >             ------ Originalnachricht ------
>> > >             Von "Adam Gundry" <adam at well-typed.com
>> > >             <mailto:adam at well-typed.com>>
>> > >             An ghc-steering-committee at haskell.org
>> > >             <mailto:ghc-steering-committee at haskell.org>
>> > >             Datum 11.11.2024 09:11:43
>> > >             Betreff [ghc-steering-committee] Please review #680:
>> > >             Clarify CRLF
>> > >             behavior in multiline strings (amendment to #569)
>> > > 
>> > >             >Dear Committee,
>> > >             >
>> > >             >Brandon Chinn proposes to amend proposal #569, which
>> > >             introduced MultilineStrings, to clarify its treatment of
>> > >             \r\n vs \n:
>> > >             >
>> > >             >https://github.com/ghc-proposals/ghc-proposals/pull/680
>> > >             <https://github.com/ghc-proposals/ghc-proposals/pull/680>
>> > >             >
>> > >             >Sebastian has volunteered to act as shepherd.
>> > >             >
>> > >             >Please guide us to a conclusion as outlined in
>> > >             >https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>> > >             >
>> > >             >Cheers,
>> > >             >
>> > >             >Adam
>> > >             >
>> > >             >-- Adam Gundry, Haskell Consultant
>> > >             >Well-Typed LLP, https://www.well-typed.com/
>> > >             <https://www.well-typed.com/>
>> > >             >
>> > >             >Registered in England & Wales, OC335890
>> > >             >27 Old Gloucester Street, London WC1N 3AX, England
>> > >             <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>> > >             >_______________________________________________
>> > >             >ghc-steering-committee mailing list
>> > >             >ghc-steering-committee at haskell.org
>> > >             <mailto:ghc-steering-committee at haskell.org>
>> > >             >https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> > >             _______________________________________________
>> > >             ghc-steering-committee mailing list
>> > >             ghc-steering-committee at haskell.org
>> > >             <mailto:ghc-steering-committee at haskell.org>
>> > >             https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> > > 
>> > > 
>> > > 
>> > >         --         Arnaud Spiwack
>> > >         Director, Research at https://moduscreate.com
>> > >         <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
>> >         _______________________________________________
>> >         ghc-steering-committee mailing list
>> >         ghc-steering-committee at haskell.org
>> >         <mailto:ghc-steering-committee at haskell.org>
>> >         https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> > 
>> >     _______________________________________________
>> >     ghc-steering-committee mailing list
>> >     ghc-steering-committee at haskell.org
>> >     <mailto:ghc-steering-committee at haskell.org>
>> >     https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> > 
>> > 
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org
>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> -- 
>> 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

From mpg at mpg.is  Mon Nov 18 14:12:03 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Mon, 18 Nov 2024 15:12:03 +0100
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <ff6db4dc-377e-4498-b065-85436ec8df06@app.fastmail.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
 <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
 <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>
 <CAJKmMz90srtSEex56eQ6FDfrjDMVdqZoKyo8ZGycAkcXiBuO6g@mail.gmail.com>
 <CAKfdd-xf-ZvG4Srp_fk4LSfhi_Z=XNTy9ZCGuRpqf1Dqoad9tg@mail.gmail.com>
 <e4e208d9-f765-448d-b5da-985d62d077fa@well-typed.com>
 <m4tjckl7cyzyahwb5uw6jm3taj2c2b3tar45tbemrrvzu6hpeg@hera.m-0.eu>
 <ff6db4dc-377e-4498-b065-85436ec8df06@app.fastmail.com>
Message-ID: <CAPxmXQwB0c9GrN0N-pJWNPT1mRuST9f+zNHM0Pagza8WLcTQ2A@mail.gmail.com>

Agree, this is what I would have expected as well.

Accept.

On Sun, 17 Nov 2024 at 17:26, Eric Seidel <eric at seidel.io> wrote:

> Makes sense, the clarification is what I would have expected.
>
> On Tue, Nov 12, 2024, at 16:28, Malte Ott wrote:
> > I agree.
> >
> > On 2024-11-12 20:58, Adam Gundry wrote:
> >> I'm happy to support this. Let's get it done for 9.12 so we don't have
> an
> >> inconsistency across versions.
> >>
> >> Adam
> >>
> >>
> >> On 12/11/2024 06:01, Moritz Angermann wrote:
> >> > I’m in support. I see the \r and \r\n as opposed to \n as legacy.
> There
> >> > of course is a problem cross-system. I just hope this will never bite
> >> > us.
> >> >
> >> > On Tue, Nov 12, 2024 at 7:42 AM Simon Peyton Jones
> >> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> >> > wrote:
> >> >
> >> >     Looks fine to me. I support.
> >> >
> >> >     Simon
> >> >
> >> >     On Mon, 11 Nov 2024 at 09:48, Sebastian Graf <sgraf1337 at gmail.com
> >> >     <mailto:sgraf1337 at gmail.com>> wrote:
> >> >
> >> >         Hi Arnaud,
> >> >
> >> >         Apologies. Indeed, your summary is apt; the proposal is in
> >> >         response to a bug report in GHC:
> >> >         https://gitlab.haskell.org/ghc/ghc/-/issues/25375
> >> >         <https://gitlab.haskell.org/ghc/ghc/-/issues/25375>
> >> >         This bug motivates splitting multiline string literals not
> only
> >> >         at `\n` characters, but at general lexical newline terminators
> >> >         as defined in Haskell2010
> >> >         <
> https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2>
> (which would also include `\r\n`, `\r` and `\f`).
> >> >         The phrasing in the proposal pre amendment can be seen as
> >> >         ambiguous: What exactly is considered a "newline"? Is it just
> >> >         `\n` or is it the `newline` lexeme specified in Haskell2010
> and
> >> >         that is used anywhere else in the report?
> >> >         The amendment merely clarifies that we mean the latter.
> >> >
> >> >         This amendment also resolves the question of whether there is
> a
> >> >         bug in the yet unreleased implementation of -XMultilineStrings
> >> >         in GHC 9.12 or in the proposal text. After this amendment, the
> >> >         bug is in GHC, where it is easily fixed
> >> >         (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432
> >> >         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432>).
> >> >
> >> >         Hence I recommend acceptance.
> >> >
> >> >         Cheers,
> >> >         Sebastian
> >> >
> >> >
> >> >         ------ Originalnachricht ------
> >> >         Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io
> >> >         <mailto:arnaud.spiwack at tweag.io>>
> >> >         An "Sebastian Graf" <sgraf1337 at gmail.com
> >> >         <mailto:sgraf1337 at gmail.com>>
> >> >         Cc "Adam Gundry" <adam at well-typed.com
> >> >         <mailto:adam at well-typed.com>>;
> >> >         ghc-steering-committee at haskell.org
> >> >         <mailto:ghc-steering-committee at haskell.org>
> >> >         Datum 11.11.2024 10:36:29
> >> >         Betreff Re: [ghc-steering-committee] Please review #680:
> Clarify
> >> >         CRLF behavior in multiline strings (amendment to #569)
> >> >
> >> > >         Sebastian,
> >> > >
> >> > >         As the shepherd you're expected to motivate your decision
> >> > >         (typically with a summary of the proposal) to guide us
> toward
> >> > >         a collective decision.
> >> > >
> >> > >         For the record, in this case, the change is that all
> >> > >         characters considered as `newline` by the report (\r, \n,
> and
> >> > >         a couple others) from the file's text are replaced by a
> single
> >> > >         `\n` in a multiline string. This isn't what the current
> >> > >         implementation does, if I understand correctly. But GHC 9.12
> >> > >         isn't released, and I think that Brandon considers the
> current
> >> > >         implementation to be a bug, because his motivation for the
> >> > >         design is to match what `unline . line` does.
> >> > >
> >> > >         I have absolutely no opinion on whether keeping \r\n or
> >> > >         converting to \n is preferable. So I'm happy to defer to
> >> > >         Sebastian.
> >> > >
> >> > >         On Mon, 11 Nov 2024 at 17:31, Sebastian Graf
> >> > >         <sgraf1337 at gmail.com <mailto:sgraf1337 at gmail.com>> wrote:
> >> > >
> >> > >             Dear Committee,
> >> > >
> >> > >             I vote accept on this very small clarifying amendment.
> >> > >
> >> > >             Cheers,
> >> > >             Sebastian
> >> > >
> >> > >
> >> > >             ------ Originalnachricht ------
> >> > >             Von "Adam Gundry" <adam at well-typed.com
> >> > >             <mailto:adam at well-typed.com>>
> >> > >             An ghc-steering-committee at haskell.org
> >> > >             <mailto:ghc-steering-committee at haskell.org>
> >> > >             Datum 11.11.2024 09:11:43
> >> > >             Betreff [ghc-steering-committee] Please review #680:
> >> > >             Clarify CRLF
> >> > >             behavior in multiline strings (amendment to #569)
> >> > >
> >> > >             >Dear Committee,
> >> > >             >
> >> > >             >Brandon Chinn proposes to amend proposal #569, which
> >> > >             introduced MultilineStrings, to clarify its treatment of
> >> > >             \r\n vs \n:
> >> > >             >
> >> > >             >
> https://github.com/ghc-proposals/ghc-proposals/pull/680
> >> > >             <
> https://github.com/ghc-proposals/ghc-proposals/pull/680>
> >> > >             >
> >> > >             >Sebastian has volunteered to act as shepherd.
> >> > >             >
> >> > >             >Please guide us to a conclusion as outlined in
> >> > >             >
> https://github.com/ghc-proposals/ghc-proposals#committee-process <
> https://github.com/ghc-proposals/ghc-proposals#committee-process>
> >> > >             >
> >> > >             >Cheers,
> >> > >             >
> >> > >             >Adam
> >> > >             >
> >> > >             >-- Adam Gundry, Haskell Consultant
> >> > >             >Well-Typed LLP, https://www.well-typed.com/
> >> > >             <https://www.well-typed.com/>
> >> > >             >
> >> > >             >Registered in England & Wales, OC335890
> >> > >             >27 Old Gloucester Street, London WC1N 3AX, England
> >> > >             <
> https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g
> >
> >> > >             >_______________________________________________
> >> > >             >ghc-steering-committee mailing list
> >> > >             >ghc-steering-committee at haskell.org
> >> > >             <mailto:ghc-steering-committee at haskell.org>
> >> > >             >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> >> > >             _______________________________________________
> >> > >             ghc-steering-committee mailing list
> >> > >             ghc-steering-committee at haskell.org
> >> > >             <mailto:ghc-steering-committee at haskell.org>
> >> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> >> > >
> >> > >
> >> > >
> >> > >         --         Arnaud Spiwack
> >> > >         Director, Research at https://moduscreate.com
> >> > >         <https://moduscreate.com> and https://tweag.io <
> https://tweag.io>.
> >> >         _______________________________________________
> >> >         ghc-steering-committee mailing list
> >> >         ghc-steering-committee at haskell.org
> >> >         <mailto:ghc-steering-committee at haskell.org>
> >> >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> >> >
> >> >     _______________________________________________
> >> >     ghc-steering-committee mailing list
> >> >     ghc-steering-committee at haskell.org
> >> >     <mailto:ghc-steering-committee at haskell.org>
> >> >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> >> >
> >> >
> >> > _______________________________________________
> >> > ghc-steering-committee mailing list
> >> > ghc-steering-committee at haskell.org
> >> >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>
> >> --
> >> 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
--  Matthías Páll Gissurarson <http://mpg.is/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20241118/e5e3f0e7/attachment-0001.html>

From sgraf1337 at gmail.com  Thu Nov 21 10:53:26 2024
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Thu, 21 Nov 2024 11:53:26 +0100
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <CAPxmXQwB0c9GrN0N-pJWNPT1mRuST9f+zNHM0Pagza8WLcTQ2A@mail.gmail.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
 <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
 <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>
 <CAJKmMz90srtSEex56eQ6FDfrjDMVdqZoKyo8ZGycAkcXiBuO6g@mail.gmail.com>
 <CAKfdd-xf-ZvG4Srp_fk4LSfhi_Z=XNTy9ZCGuRpqf1Dqoad9tg@mail.gmail.com>
 <e4e208d9-f765-448d-b5da-985d62d077fa@well-typed.com>
 <m4tjckl7cyzyahwb5uw6jm3taj2c2b3tar45tbemrrvzu6hpeg@hera.m-0.eu>
 <ff6db4dc-377e-4498-b065-85436ec8df06@app.fastmail.com>
 <CAPxmXQwB0c9GrN0N-pJWNPT1mRuST9f+zNHM0Pagza8WLcTQ2A@mail.gmail.com>
Message-ID: <CAAS+=P9VURBmw1KqxPRYCvsU4Dgu+QZYjyGuJc7PJQBTPKOZQw@mail.gmail.com>

9 out of 11 members have voiced support for the proposal, with one
additional member being indifferent.
I would like to announce this proposal as accepted, but I am unsure if it
is my job as a shepherd to do so, and whether we should wait for on the
remaining vote.

This is what is written in the process bylaws:

Ideally, the committee reaches consensus, as determined by the secretary or
> the shepherd. If consensus is elusive, then we vote, with the Simons
> retaining veto power.
>
> This phase should conclude within a month.


Does 9,5 out of 11 mean we reached a consensus? Should we/I wait for a full
month to pass before taking action?

Thanks,
Sebastian


Am Mo., 18. Nov. 2024 um 15:12 Uhr schrieb Matthías Páll Gissurarson <
mpg at mpg.is>:

> Agree, this is what I would have expected as well.
>
> Accept.
>
> On Sun, 17 Nov 2024 at 17:26, Eric Seidel <eric at seidel.io> wrote:
>
>> Makes sense, the clarification is what I would have expected.
>>
>> On Tue, Nov 12, 2024, at 16:28, Malte Ott wrote:
>> > I agree.
>> >
>> > On 2024-11-12 20:58, Adam Gundry wrote:
>> >> I'm happy to support this. Let's get it done for 9.12 so we don't have
>> an
>> >> inconsistency across versions.
>> >>
>> >> Adam
>> >>
>> >>
>> >> On 12/11/2024 06:01, Moritz Angermann wrote:
>> >> > I’m in support. I see the \r and \r\n as opposed to \n as legacy.
>> There
>> >> > of course is a problem cross-system. I just hope this will never bite
>> >> > us.
>> >> >
>> >> > On Tue, Nov 12, 2024 at 7:42 AM Simon Peyton Jones
>> >> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>> >> > wrote:
>> >> >
>> >> >     Looks fine to me. I support.
>> >> >
>> >> >     Simon
>> >> >
>> >> >     On Mon, 11 Nov 2024 at 09:48, Sebastian Graf <
>> sgraf1337 at gmail.com
>> >> >     <mailto:sgraf1337 at gmail.com>> wrote:
>> >> >
>> >> >         Hi Arnaud,
>> >> >
>> >> >         Apologies. Indeed, your summary is apt; the proposal is in
>> >> >         response to a bug report in GHC:
>> >> >         https://gitlab.haskell.org/ghc/ghc/-/issues/25375
>> >> >         <https://gitlab.haskell.org/ghc/ghc/-/issues/25375>
>> >> >         This bug motivates splitting multiline string literals not
>> only
>> >> >         at `\n` characters, but at general lexical newline
>> terminators
>> >> >         as defined in Haskell2010
>> >> >         <
>> https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2>
>> (which would also include `\r\n`, `\r` and `\f`).
>> >> >         The phrasing in the proposal pre amendment can be seen as
>> >> >         ambiguous: What exactly is considered a "newline"? Is it just
>> >> >         `\n` or is it the `newline` lexeme specified in Haskell2010
>> and
>> >> >         that is used anywhere else in the report?
>> >> >         The amendment merely clarifies that we mean the latter.
>> >> >
>> >> >         This amendment also resolves the question of whether there
>> is a
>> >> >         bug in the yet unreleased implementation of
>> -XMultilineStrings
>> >> >         in GHC 9.12 or in the proposal text. After this amendment,
>> the
>> >> >         bug is in GHC, where it is easily fixed
>> >> >         (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432
>> >> >         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432
>> >).
>> >> >
>> >> >         Hence I recommend acceptance.
>> >> >
>> >> >         Cheers,
>> >> >         Sebastian
>> >> >
>> >> >
>> >> >         ------ Originalnachricht ------
>> >> >         Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io
>> >> >         <mailto:arnaud.spiwack at tweag.io>>
>> >> >         An "Sebastian Graf" <sgraf1337 at gmail.com
>> >> >         <mailto:sgraf1337 at gmail.com>>
>> >> >         Cc "Adam Gundry" <adam at well-typed.com
>> >> >         <mailto:adam at well-typed.com>>;
>> >> >         ghc-steering-committee at haskell.org
>> >> >         <mailto:ghc-steering-committee at haskell.org>
>> >> >         Datum 11.11.2024 10:36:29
>> >> >         Betreff Re: [ghc-steering-committee] Please review #680:
>> Clarify
>> >> >         CRLF behavior in multiline strings (amendment to #569)
>> >> >
>> >> > >         Sebastian,
>> >> > >
>> >> > >         As the shepherd you're expected to motivate your decision
>> >> > >         (typically with a summary of the proposal) to guide us
>> toward
>> >> > >         a collective decision.
>> >> > >
>> >> > >         For the record, in this case, the change is that all
>> >> > >         characters considered as `newline` by the report (\r, \n,
>> and
>> >> > >         a couple others) from the file's text are replaced by a
>> single
>> >> > >         `\n` in a multiline string. This isn't what the current
>> >> > >         implementation does, if I understand correctly. But GHC
>> 9.12
>> >> > >         isn't released, and I think that Brandon considers the
>> current
>> >> > >         implementation to be a bug, because his motivation for the
>> >> > >         design is to match what `unline . line` does.
>> >> > >
>> >> > >         I have absolutely no opinion on whether keeping \r\n or
>> >> > >         converting to \n is preferable. So I'm happy to defer to
>> >> > >         Sebastian.
>> >> > >
>> >> > >         On Mon, 11 Nov 2024 at 17:31, Sebastian Graf
>> >> > >         <sgraf1337 at gmail.com <mailto:sgraf1337 at gmail.com>> wrote:
>> >> > >
>> >> > >             Dear Committee,
>> >> > >
>> >> > >             I vote accept on this very small clarifying amendment.
>> >> > >
>> >> > >             Cheers,
>> >> > >             Sebastian
>> >> > >
>> >> > >
>> >> > >             ------ Originalnachricht ------
>> >> > >             Von "Adam Gundry" <adam at well-typed.com
>> >> > >             <mailto:adam at well-typed.com>>
>> >> > >             An ghc-steering-committee at haskell.org
>> >> > >             <mailto:ghc-steering-committee at haskell.org>
>> >> > >             Datum 11.11.2024 09:11:43
>> >> > >             Betreff [ghc-steering-committee] Please review #680:
>> >> > >             Clarify CRLF
>> >> > >             behavior in multiline strings (amendment to #569)
>> >> > >
>> >> > >             >Dear Committee,
>> >> > >             >
>> >> > >             >Brandon Chinn proposes to amend proposal #569, which
>> >> > >             introduced MultilineStrings, to clarify its treatment
>> of
>> >> > >             \r\n vs \n:
>> >> > >             >
>> >> > >             >
>> https://github.com/ghc-proposals/ghc-proposals/pull/680
>> >> > >             <
>> https://github.com/ghc-proposals/ghc-proposals/pull/680>
>> >> > >             >
>> >> > >             >Sebastian has volunteered to act as shepherd.
>> >> > >             >
>> >> > >             >Please guide us to a conclusion as outlined in
>> >> > >             >
>> https://github.com/ghc-proposals/ghc-proposals#committee-process <
>> https://github.com/ghc-proposals/ghc-proposals#committee-process>
>> >> > >             >
>> >> > >             >Cheers,
>> >> > >             >
>> >> > >             >Adam
>> >> > >             >
>> >> > >             >-- Adam Gundry, Haskell Consultant
>> >> > >             >Well-Typed LLP, https://www.well-typed.com/
>> >> > >             <https://www.well-typed.com/>
>> >> > >             >
>> >> > >             >Registered in England & Wales, OC335890
>> >> > >             >27 Old Gloucester Street, London WC1N 3AX, England
>> >> > >             <
>> https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g
>> >
>> >> > >             >_______________________________________________
>> >> > >             >ghc-steering-committee mailing list
>> >> > >             >ghc-steering-committee at haskell.org
>> >> > >             <mailto:ghc-steering-committee at haskell.org>
>> >> > >             >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> >> > >             _______________________________________________
>> >> > >             ghc-steering-committee mailing list
>> >> > >             ghc-steering-committee at haskell.org
>> >> > >             <mailto:ghc-steering-committee at haskell.org>
>> >> > >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> >> > >
>> >> > >
>> >> > >
>> >> > >         --         Arnaud Spiwack
>> >> > >         Director, Research at https://moduscreate.com
>> >> > >         <https://moduscreate.com> and https://tweag.io <
>> https://tweag.io>.
>> >> >         _______________________________________________
>> >> >         ghc-steering-committee mailing list
>> >> >         ghc-steering-committee at haskell.org
>> >> >         <mailto:ghc-steering-committee at haskell.org>
>> >> >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> >> >
>> >> >     _______________________________________________
>> >> >     ghc-steering-committee mailing list
>> >> >     ghc-steering-committee at haskell.org
>> >> >     <mailto:ghc-steering-committee at haskell.org>
>> >> >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > ghc-steering-committee mailing list
>> >> > ghc-steering-committee at haskell.org
>> >> >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >>
>> >> --
>> >> 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
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> --  Matthías Páll Gissurarson <http://mpg.is/>
> _______________________________________________
> 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/20241121/61c9fcdb/attachment-0001.html>

From simon.peytonjones at gmail.com  Thu Nov 21 11:19:33 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 21 Nov 2024 11:19:33 +0000
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <CAAS+=P9VURBmw1KqxPRYCvsU4Dgu+QZYjyGuJc7PJQBTPKOZQw@mail.gmail.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
 <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
 <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>
 <CAJKmMz90srtSEex56eQ6FDfrjDMVdqZoKyo8ZGycAkcXiBuO6g@mail.gmail.com>
 <CAKfdd-xf-ZvG4Srp_fk4LSfhi_Z=XNTy9ZCGuRpqf1Dqoad9tg@mail.gmail.com>
 <e4e208d9-f765-448d-b5da-985d62d077fa@well-typed.com>
 <m4tjckl7cyzyahwb5uw6jm3taj2c2b3tar45tbemrrvzu6hpeg@hera.m-0.eu>
 <ff6db4dc-377e-4498-b065-85436ec8df06@app.fastmail.com>
 <CAPxmXQwB0c9GrN0N-pJWNPT1mRuST9f+zNHM0Pagza8WLcTQ2A@mail.gmail.com>
 <CAAS+=P9VURBmw1KqxPRYCvsU4Dgu+QZYjyGuJc7PJQBTPKOZQw@mail.gmail.com>
Message-ID: <CAJKmMz9KyRa28P3YeY6e0SqfEFY3-sdpE2ktS6a4LLFdtmO8xw@mail.gmail.com>

For a small non-controversial proposal, 9 votes is plenty.  Merge!

Simon

On Thu, 21 Nov 2024 at 10:53, Sebastian Graf <sgraf1337 at gmail.com> wrote:

> 9 out of 11 members have voiced support for the proposal, with one
> additional member being indifferent.
> I would like to announce this proposal as accepted, but I am unsure if it
> is my job as a shepherd to do so, and whether we should wait for on the
> remaining vote.
>
> This is what is written in the process bylaws:
>
> Ideally, the committee reaches consensus, as determined by the secretary
>> or the shepherd. If consensus is elusive, then we vote, with the Simons
>> retaining veto power.
>>
>> This phase should conclude within a month.
>
>
> Does 9,5 out of 11 mean we reached a consensus? Should we/I wait for a
> full month to pass before taking action?
>
> Thanks,
> Sebastian
>
>
> Am Mo., 18. Nov. 2024 um 15:12 Uhr schrieb Matthías Páll Gissurarson <
> mpg at mpg.is>:
>
>> Agree, this is what I would have expected as well.
>>
>> Accept.
>>
>> On Sun, 17 Nov 2024 at 17:26, Eric Seidel <eric at seidel.io> wrote:
>>
>>> Makes sense, the clarification is what I would have expected.
>>>
>>> On Tue, Nov 12, 2024, at 16:28, Malte Ott wrote:
>>> > I agree.
>>> >
>>> > On 2024-11-12 20:58, Adam Gundry wrote:
>>> >> I'm happy to support this. Let's get it done for 9.12 so we don't
>>> have an
>>> >> inconsistency across versions.
>>> >>
>>> >> Adam
>>> >>
>>> >>
>>> >> On 12/11/2024 06:01, Moritz Angermann wrote:
>>> >> > I’m in support. I see the \r and \r\n as opposed to \n as legacy.
>>> There
>>> >> > of course is a problem cross-system. I just hope this will never
>>> bite
>>> >> > us.
>>> >> >
>>> >> > On Tue, Nov 12, 2024 at 7:42 AM Simon Peyton Jones
>>> >> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>>> >> > wrote:
>>> >> >
>>> >> >     Looks fine to me. I support.
>>> >> >
>>> >> >     Simon
>>> >> >
>>> >> >     On Mon, 11 Nov 2024 at 09:48, Sebastian Graf <
>>> sgraf1337 at gmail.com
>>> >> >     <mailto:sgraf1337 at gmail.com>> wrote:
>>> >> >
>>> >> >         Hi Arnaud,
>>> >> >
>>> >> >         Apologies. Indeed, your summary is apt; the proposal is in
>>> >> >         response to a bug report in GHC:
>>> >> >         https://gitlab.haskell.org/ghc/ghc/-/issues/25375
>>> >> >         <https://gitlab.haskell.org/ghc/ghc/-/issues/25375>
>>> >> >         This bug motivates splitting multiline string literals not
>>> only
>>> >> >         at `\n` characters, but at general lexical newline
>>> terminators
>>> >> >         as defined in Haskell2010
>>> >> >         <
>>> https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2>
>>> (which would also include `\r\n`, `\r` and `\f`).
>>> >> >         The phrasing in the proposal pre amendment can be seen as
>>> >> >         ambiguous: What exactly is considered a "newline"? Is it
>>> just
>>> >> >         `\n` or is it the `newline` lexeme specified in Haskell2010
>>> and
>>> >> >         that is used anywhere else in the report?
>>> >> >         The amendment merely clarifies that we mean the latter.
>>> >> >
>>> >> >         This amendment also resolves the question of whether there
>>> is a
>>> >> >         bug in the yet unreleased implementation of
>>> -XMultilineStrings
>>> >> >         in GHC 9.12 or in the proposal text. After this amendment,
>>> the
>>> >> >         bug is in GHC, where it is easily fixed
>>> >> >         (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432
>>> >> >         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432
>>> >).
>>> >> >
>>> >> >         Hence I recommend acceptance.
>>> >> >
>>> >> >         Cheers,
>>> >> >         Sebastian
>>> >> >
>>> >> >
>>> >> >         ------ Originalnachricht ------
>>> >> >         Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io
>>> >> >         <mailto:arnaud.spiwack at tweag.io>>
>>> >> >         An "Sebastian Graf" <sgraf1337 at gmail.com
>>> >> >         <mailto:sgraf1337 at gmail.com>>
>>> >> >         Cc "Adam Gundry" <adam at well-typed.com
>>> >> >         <mailto:adam at well-typed.com>>;
>>> >> >         ghc-steering-committee at haskell.org
>>> >> >         <mailto:ghc-steering-committee at haskell.org>
>>> >> >         Datum 11.11.2024 10:36:29
>>> >> >         Betreff Re: [ghc-steering-committee] Please review #680:
>>> Clarify
>>> >> >         CRLF behavior in multiline strings (amendment to #569)
>>> >> >
>>> >> > >         Sebastian,
>>> >> > >
>>> >> > >         As the shepherd you're expected to motivate your decision
>>> >> > >         (typically with a summary of the proposal) to guide us
>>> toward
>>> >> > >         a collective decision.
>>> >> > >
>>> >> > >         For the record, in this case, the change is that all
>>> >> > >         characters considered as `newline` by the report (\r, \n,
>>> and
>>> >> > >         a couple others) from the file's text are replaced by a
>>> single
>>> >> > >         `\n` in a multiline string. This isn't what the current
>>> >> > >         implementation does, if I understand correctly. But GHC
>>> 9.12
>>> >> > >         isn't released, and I think that Brandon considers the
>>> current
>>> >> > >         implementation to be a bug, because his motivation for the
>>> >> > >         design is to match what `unline . line` does.
>>> >> > >
>>> >> > >         I have absolutely no opinion on whether keeping \r\n or
>>> >> > >         converting to \n is preferable. So I'm happy to defer to
>>> >> > >         Sebastian.
>>> >> > >
>>> >> > >         On Mon, 11 Nov 2024 at 17:31, Sebastian Graf
>>> >> > >         <sgraf1337 at gmail.com <mailto:sgraf1337 at gmail.com>> wrote:
>>> >> > >
>>> >> > >             Dear Committee,
>>> >> > >
>>> >> > >             I vote accept on this very small clarifying amendment.
>>> >> > >
>>> >> > >             Cheers,
>>> >> > >             Sebastian
>>> >> > >
>>> >> > >
>>> >> > >             ------ Originalnachricht ------
>>> >> > >             Von "Adam Gundry" <adam at well-typed.com
>>> >> > >             <mailto:adam at well-typed.com>>
>>> >> > >             An ghc-steering-committee at haskell.org
>>> >> > >             <mailto:ghc-steering-committee at haskell.org>
>>> >> > >             Datum 11.11.2024 09:11:43
>>> >> > >             Betreff [ghc-steering-committee] Please review #680:
>>> >> > >             Clarify CRLF
>>> >> > >             behavior in multiline strings (amendment to #569)
>>> >> > >
>>> >> > >             >Dear Committee,
>>> >> > >             >
>>> >> > >             >Brandon Chinn proposes to amend proposal #569, which
>>> >> > >             introduced MultilineStrings, to clarify its treatment
>>> of
>>> >> > >             \r\n vs \n:
>>> >> > >             >
>>> >> > >             >
>>> https://github.com/ghc-proposals/ghc-proposals/pull/680
>>> >> > >             <
>>> https://github.com/ghc-proposals/ghc-proposals/pull/680>
>>> >> > >             >
>>> >> > >             >Sebastian has volunteered to act as shepherd.
>>> >> > >             >
>>> >> > >             >Please guide us to a conclusion as outlined in
>>> >> > >             >
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process <
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process>
>>> >> > >             >
>>> >> > >             >Cheers,
>>> >> > >             >
>>> >> > >             >Adam
>>> >> > >             >
>>> >> > >             >-- Adam Gundry, Haskell Consultant
>>> >> > >             >Well-Typed LLP, https://www.well-typed.com/
>>> >> > >             <https://www.well-typed.com/>
>>> >> > >             >
>>> >> > >             >Registered in England & Wales, OC335890
>>> >> > >             >27 Old Gloucester Street, London WC1N 3AX, England
>>> >> > >             <
>>> https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g
>>> >
>>> >> > >             >_______________________________________________
>>> >> > >             >ghc-steering-committee mailing list
>>> >> > >             >ghc-steering-committee at haskell.org
>>> >> > >             <mailto:ghc-steering-committee at haskell.org>
>>> >> > >             >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> <
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> >
>>> >> > >             _______________________________________________
>>> >> > >             ghc-steering-committee mailing list
>>> >> > >             ghc-steering-committee at haskell.org
>>> >> > >             <mailto:ghc-steering-committee at haskell.org>
>>> >> > >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> <
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >         --         Arnaud Spiwack
>>> >> > >         Director, Research at https://moduscreate.com
>>> >> > >         <https://moduscreate.com> and https://tweag.io <
>>> https://tweag.io>.
>>> >> >         _______________________________________________
>>> >> >         ghc-steering-committee mailing list
>>> >> >         ghc-steering-committee at haskell.org
>>> >> >         <mailto:ghc-steering-committee at haskell.org>
>>> >> >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> <
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> >
>>> >> >
>>> >> >     _______________________________________________
>>> >> >     ghc-steering-committee mailing list
>>> >> >     ghc-steering-committee at haskell.org
>>> >> >     <mailto:ghc-steering-committee at haskell.org>
>>> >> >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> <
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > ghc-steering-committee mailing list
>>> >> > ghc-steering-committee at haskell.org
>>> >> >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> >>
>>> >> --
>>> >> 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
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>>
>> --
>> --  Matthías Páll Gissurarson <http://mpg.is/>
>> _______________________________________________
>> 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/20241121/8557e30e/attachment-0001.html>

From sgraf1337 at gmail.com  Thu Nov 21 11:59:07 2024
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Thu, 21 Nov 2024 12:59:07 +0100
Subject: [ghc-steering-committee] Please review #680: Clarify CRLF
 behavior in multiline strings (amendment to #569)
In-Reply-To: <CAJKmMz9KyRa28P3YeY6e0SqfEFY3-sdpE2ktS6a4LLFdtmO8xw@mail.gmail.com>
References: <c3dea74f-e520-4bc8-9976-cc4891bc27cc@well-typed.com>
 <em8200c515-892b-4f86-b5bf-75806fce6280@4a2fe044.com>
 <CAGwnsn=9u_m=0ew5KxD_uYXoRU4_cBvh3tG+Q0yDy34wv1v_Cw@mail.gmail.com>
 <em468d5152-50b5-415d-9117-d075e9e530d7@4a2fe044.com>
 <CAJKmMz90srtSEex56eQ6FDfrjDMVdqZoKyo8ZGycAkcXiBuO6g@mail.gmail.com>
 <CAKfdd-xf-ZvG4Srp_fk4LSfhi_Z=XNTy9ZCGuRpqf1Dqoad9tg@mail.gmail.com>
 <e4e208d9-f765-448d-b5da-985d62d077fa@well-typed.com>
 <m4tjckl7cyzyahwb5uw6jm3taj2c2b3tar45tbemrrvzu6hpeg@hera.m-0.eu>
 <ff6db4dc-377e-4498-b065-85436ec8df06@app.fastmail.com>
 <CAPxmXQwB0c9GrN0N-pJWNPT1mRuST9f+zNHM0Pagza8WLcTQ2A@mail.gmail.com>
 <CAAS+=P9VURBmw1KqxPRYCvsU4Dgu+QZYjyGuJc7PJQBTPKOZQw@mail.gmail.com>
 <CAJKmMz9KyRa28P3YeY6e0SqfEFY3-sdpE2ktS6a4LLFdtmO8xw@mail.gmail.com>
Message-ID: <CAAS+=P9w1FTv2kSJHvwk48dQ0w-HK_SsEXkS2=EKJqqz_tBpCQ@mail.gmail.com>

Then I declare this proposal accepted by the committee.

Am Do., 21. Nov. 2024 um 12:19 Uhr schrieb Simon Peyton Jones <
simon.peytonjones at gmail.com>:

> For a small non-controversial proposal, 9 votes is plenty.  Merge!
>
> Simon
>
> On Thu, 21 Nov 2024 at 10:53, Sebastian Graf <sgraf1337 at gmail.com> wrote:
>
>> 9 out of 11 members have voiced support for the proposal, with one
>> additional member being indifferent.
>> I would like to announce this proposal as accepted, but I am unsure if it
>> is my job as a shepherd to do so, and whether we should wait for on the
>> remaining vote.
>>
>> This is what is written in the process bylaws:
>>
>> Ideally, the committee reaches consensus, as determined by the secretary
>>> or the shepherd. If consensus is elusive, then we vote, with the Simons
>>> retaining veto power.
>>>
>>> This phase should conclude within a month.
>>
>>
>> Does 9,5 out of 11 mean we reached a consensus? Should we/I wait for a
>> full month to pass before taking action?
>>
>> Thanks,
>> Sebastian
>>
>>
>> Am Mo., 18. Nov. 2024 um 15:12 Uhr schrieb Matthías Páll Gissurarson <
>> mpg at mpg.is>:
>>
>>> Agree, this is what I would have expected as well.
>>>
>>> Accept.
>>>
>>> On Sun, 17 Nov 2024 at 17:26, Eric Seidel <eric at seidel.io> wrote:
>>>
>>>> Makes sense, the clarification is what I would have expected.
>>>>
>>>> On Tue, Nov 12, 2024, at 16:28, Malte Ott wrote:
>>>> > I agree.
>>>> >
>>>> > On 2024-11-12 20:58, Adam Gundry wrote:
>>>> >> I'm happy to support this. Let's get it done for 9.12 so we don't
>>>> have an
>>>> >> inconsistency across versions.
>>>> >>
>>>> >> Adam
>>>> >>
>>>> >>
>>>> >> On 12/11/2024 06:01, Moritz Angermann wrote:
>>>> >> > I’m in support. I see the \r and \r\n as opposed to \n as legacy.
>>>> There
>>>> >> > of course is a problem cross-system. I just hope this will never
>>>> bite
>>>> >> > us.
>>>> >> >
>>>> >> > On Tue, Nov 12, 2024 at 7:42 AM Simon Peyton Jones
>>>> >> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>>>> >> > wrote:
>>>> >> >
>>>> >> >     Looks fine to me. I support.
>>>> >> >
>>>> >> >     Simon
>>>> >> >
>>>> >> >     On Mon, 11 Nov 2024 at 09:48, Sebastian Graf <
>>>> sgraf1337 at gmail.com
>>>> >> >     <mailto:sgraf1337 at gmail.com>> wrote:
>>>> >> >
>>>> >> >         Hi Arnaud,
>>>> >> >
>>>> >> >         Apologies. Indeed, your summary is apt; the proposal is in
>>>> >> >         response to a bug report in GHC:
>>>> >> >         https://gitlab.haskell.org/ghc/ghc/-/issues/25375
>>>> >> >         <https://gitlab.haskell.org/ghc/ghc/-/issues/25375>
>>>> >> >         This bug motivates splitting multiline string literals not
>>>> only
>>>> >> >         at `\n` characters, but at general lexical newline
>>>> terminators
>>>> >> >         as defined in Haskell2010
>>>> >> >         <
>>>> https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2>
>>>> (which would also include `\r\n`, `\r` and `\f`).
>>>> >> >         The phrasing in the proposal pre amendment can be seen as
>>>> >> >         ambiguous: What exactly is considered a "newline"? Is it
>>>> just
>>>> >> >         `\n` or is it the `newline` lexeme specified in
>>>> Haskell2010 and
>>>> >> >         that is used anywhere else in the report?
>>>> >> >         The amendment merely clarifies that we mean the latter.
>>>> >> >
>>>> >> >         This amendment also resolves the question of whether there
>>>> is a
>>>> >> >         bug in the yet unreleased implementation of
>>>> -XMultilineStrings
>>>> >> >         in GHC 9.12 or in the proposal text. After this amendment,
>>>> the
>>>> >> >         bug is in GHC, where it is easily fixed
>>>> >> >         (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432
>>>> >> >         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13432
>>>> >).
>>>> >> >
>>>> >> >         Hence I recommend acceptance.
>>>> >> >
>>>> >> >         Cheers,
>>>> >> >         Sebastian
>>>> >> >
>>>> >> >
>>>> >> >         ------ Originalnachricht ------
>>>> >> >         Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io
>>>> >> >         <mailto:arnaud.spiwack at tweag.io>>
>>>> >> >         An "Sebastian Graf" <sgraf1337 at gmail.com
>>>> >> >         <mailto:sgraf1337 at gmail.com>>
>>>> >> >         Cc "Adam Gundry" <adam at well-typed.com
>>>> >> >         <mailto:adam at well-typed.com>>;
>>>> >> >         ghc-steering-committee at haskell.org
>>>> >> >         <mailto:ghc-steering-committee at haskell.org>
>>>> >> >         Datum 11.11.2024 10:36:29
>>>> >> >         Betreff Re: [ghc-steering-committee] Please review #680:
>>>> Clarify
>>>> >> >         CRLF behavior in multiline strings (amendment to #569)
>>>> >> >
>>>> >> > >         Sebastian,
>>>> >> > >
>>>> >> > >         As the shepherd you're expected to motivate your decision
>>>> >> > >         (typically with a summary of the proposal) to guide us
>>>> toward
>>>> >> > >         a collective decision.
>>>> >> > >
>>>> >> > >         For the record, in this case, the change is that all
>>>> >> > >         characters considered as `newline` by the report (\r,
>>>> \n, and
>>>> >> > >         a couple others) from the file's text are replaced by a
>>>> single
>>>> >> > >         `\n` in a multiline string. This isn't what the current
>>>> >> > >         implementation does, if I understand correctly. But GHC
>>>> 9.12
>>>> >> > >         isn't released, and I think that Brandon considers the
>>>> current
>>>> >> > >         implementation to be a bug, because his motivation for
>>>> the
>>>> >> > >         design is to match what `unline . line` does.
>>>> >> > >
>>>> >> > >         I have absolutely no opinion on whether keeping \r\n or
>>>> >> > >         converting to \n is preferable. So I'm happy to defer to
>>>> >> > >         Sebastian.
>>>> >> > >
>>>> >> > >         On Mon, 11 Nov 2024 at 17:31, Sebastian Graf
>>>> >> > >         <sgraf1337 at gmail.com <mailto:sgraf1337 at gmail.com>>
>>>> wrote:
>>>> >> > >
>>>> >> > >             Dear Committee,
>>>> >> > >
>>>> >> > >             I vote accept on this very small clarifying
>>>> amendment.
>>>> >> > >
>>>> >> > >             Cheers,
>>>> >> > >             Sebastian
>>>> >> > >
>>>> >> > >
>>>> >> > >             ------ Originalnachricht ------
>>>> >> > >             Von "Adam Gundry" <adam at well-typed.com
>>>> >> > >             <mailto:adam at well-typed.com>>
>>>> >> > >             An ghc-steering-committee at haskell.org
>>>> >> > >             <mailto:ghc-steering-committee at haskell.org>
>>>> >> > >             Datum 11.11.2024 09:11:43
>>>> >> > >             Betreff [ghc-steering-committee] Please review #680:
>>>> >> > >             Clarify CRLF
>>>> >> > >             behavior in multiline strings (amendment to #569)
>>>> >> > >
>>>> >> > >             >Dear Committee,
>>>> >> > >             >
>>>> >> > >             >Brandon Chinn proposes to amend proposal #569, which
>>>> >> > >             introduced MultilineStrings, to clarify its
>>>> treatment of
>>>> >> > >             \r\n vs \n:
>>>> >> > >             >
>>>> >> > >             >
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/680
>>>> >> > >             <
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/680>
>>>> >> > >             >
>>>> >> > >             >Sebastian has volunteered to act as shepherd.
>>>> >> > >             >
>>>> >> > >             >Please guide us to a conclusion as outlined in
>>>> >> > >             >
>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process <
>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process>
>>>> >> > >             >
>>>> >> > >             >Cheers,
>>>> >> > >             >
>>>> >> > >             >Adam
>>>> >> > >             >
>>>> >> > >             >-- Adam Gundry, Haskell Consultant
>>>> >> > >             >Well-Typed LLP, https://www.well-typed.com/
>>>> >> > >             <https://www.well-typed.com/>
>>>> >> > >             >
>>>> >> > >             >Registered in England & Wales, OC335890
>>>> >> > >             >27 Old Gloucester Street, London WC1N 3AX, England
>>>> >> > >             <
>>>> https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g
>>>> >
>>>> >> > >             >_______________________________________________
>>>> >> > >             >ghc-steering-committee mailing list
>>>> >> > >             >ghc-steering-committee at haskell.org
>>>> >> > >             <mailto:ghc-steering-committee at haskell.org>
>>>> >> > >             >
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> <
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> >
>>>> >> > >             _______________________________________________
>>>> >> > >             ghc-steering-committee mailing list
>>>> >> > >             ghc-steering-committee at haskell.org
>>>> >> > >             <mailto:ghc-steering-committee at haskell.org>
>>>> >> > >
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> <
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> >
>>>> >> > >
>>>> >> > >
>>>> >> > >
>>>> >> > >         --         Arnaud Spiwack
>>>> >> > >         Director, Research at https://moduscreate.com
>>>> >> > >         <https://moduscreate.com> and https://tweag.io <
>>>> https://tweag.io>.
>>>> >> >         _______________________________________________
>>>> >> >         ghc-steering-committee mailing list
>>>> >> >         ghc-steering-committee at haskell.org
>>>> >> >         <mailto:ghc-steering-committee at haskell.org>
>>>> >> >
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> <
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> >
>>>> >> >
>>>> >> >     _______________________________________________
>>>> >> >     ghc-steering-committee mailing list
>>>> >> >     ghc-steering-committee at haskell.org
>>>> >> >     <mailto:ghc-steering-committee at haskell.org>
>>>> >> >
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> <
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> >
>>>> >> >
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > ghc-steering-committee mailing list
>>>> >> > ghc-steering-committee at haskell.org
>>>> >> >
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> >>
>>>> >> --
>>>> >> 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
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>>
>>> --
>>> --  Matthías Páll Gissurarson <http://mpg.is/>
>>> _______________________________________________
>>> 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/20241121/2715da87/attachment-0001.html>