Please review #680: Clarify CRLF behavior in multiline strings (amendment to #569)

older
Please review #673: Amendment to...

Adam Gundry

11 Nov 2024 11 Nov '24

3:11 a.m.

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

Show replies by date

Sebastian Graf

11 Nov 11 Nov

3:31 a.m.

Dear Committee, I vote accept on this very small clarifying amendment. Cheers, Sebastian ------ Originalnachricht ------ Von "Adam Gundry" An ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Arnaud Spiwack

4:36 a.m.

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 wrote:

...

Dear Committee,

I vote accept on this very small clarifying amendment.

Cheers, Sebastian

------ Originalnachricht ------ Von "Adam Gundry" An ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@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.

Sebastian Graf

4:48 a.m.

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" An "Sebastian Graf" Cc "Adam Gundry" ; ghc-steering-committee@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 wrote:

...
Dear Committee,

I vote accept on this very small clarifying amendment.

Cheers, Sebastian

------ Originalnachricht ------ Von "Adam Gundry" An ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@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.

Simon Peyton Jones

5:41 p.m.

Looks fine to me. I support. Simon On Mon, 11 Nov 2024 at 09:48, Sebastian Graf 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" An "Sebastian Graf" Cc "Adam Gundry" ; ghc-steering-committee@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 wrote:

...
Dear Committee,

I vote accept on this very small clarifying amendment.

Cheers, Sebastian

------ Originalnachricht ------ Von "Adam Gundry" An ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Moritz Angermann

12 Nov 12 Nov

1:01 a.m.

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@gmail.com> wrote:

...

Looks fine to me. I support.

Simon

On Mon, 11 Nov 2024 at 09:48, Sebastian Graf 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" An "Sebastian Graf" Cc "Adam Gundry" ; ghc-steering-committee@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 wrote:

...
Dear Committee,

I vote accept on this very small clarifying amendment.

Cheers, Sebastian

------ Originalnachricht ------ Von "Adam Gundry" An ghc-steering-committee@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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Jakob Brünker

3:58 p.m.

I'm in support. Not matching the behavior of unlines would be odd. On Tue, Nov 12, 2024 at 7:02 AM 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@gmail.com> wrote:

...
Looks fine to me. I support.

Simon

On Mon, 11 Nov 2024 at 09:48, Sebastian Graf 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" An "Sebastian Graf" Cc "Adam Gundry" ; ghc-steering-committee@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 wrote:

...
Dear Committee,

I vote accept on this very small clarifying amendment.

Cheers, Sebastian

------ Originalnachricht ------ Von "Adam Gundry" An ghc-steering-committee@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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Adam Gundry

3:58 p.m.

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 mailto:simon.peytonjones@gmail.com> wrote:

Looks fine to me. I support.

Simon

On Mon, 11 Nov 2024 at 09:48, Sebastian Graf mailto:sgraf1337@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" mailto:arnaud.spiwack@tweag.io> An "Sebastian Graf" mailto:sgraf1337@gmail.com> Cc "Adam Gundry" mailto:adam@well-typed.com>; ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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 mailto:sgraf1337@gmail.com> wrote:

Dear Committee,

I vote accept on this very small clarifying amendment.

Cheers, Sebastian

------ Originalnachricht ------ Von "Adam Gundry" mailto:adam@well-typed.com> An ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@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

Malte Ott

5:28 p.m.

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 mailto:simon.peytonjones@gmail.com> wrote:

Looks fine to me. I support.

Simon

On Mon, 11 Nov 2024 at 09:48, Sebastian Graf mailto:sgraf1337@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" mailto:arnaud.spiwack@tweag.io> An "Sebastian Graf" mailto:sgraf1337@gmail.com> Cc "Adam Gundry" mailto:adam@well-typed.com>; ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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 mailto:sgraf1337@gmail.com> wrote:

Dear Committee,

I vote accept on this very small clarifying amendment.

Cheers, Sebastian

------ Originalnachricht ------ Von "Adam Gundry" mailto:adam@well-typed.com> An ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Eric Seidel

17 Nov 17 Nov

11:26 a.m.

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 mailto:simon.peytonjones@gmail.com> wrote:

Looks fine to me. I support.

Simon

On Mon, 11 Nov 2024 at 09:48, Sebastian Graf mailto:sgraf1337@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" mailto:arnaud.spiwack@tweag.io> An "Sebastian Graf" mailto:sgraf1337@gmail.com> Cc "Adam Gundry" mailto:adam@well-typed.com>; ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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 mailto:sgraf1337@gmail.com> wrote:

Dear Committee,

I vote accept on this very small clarifying amendment.

Cheers, Sebastian

------ Originalnachricht ------ Von "Adam Gundry" mailto:adam@well-typed.com> An ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Matthías Páll Gissurarson

18 Nov 18 Nov

9:12 a.m.

Agree, this is what I would have expected as well. Accept. On Sun, 17 Nov 2024 at 17:26, Eric Seidel 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 mailto:simon.peytonjones@gmail.com> wrote:

Looks fine to me. I support.

Simon

On Mon, 11 Nov 2024 at 09:48, Sebastian Graf mailto:sgraf1337@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" mailto:arnaud.spiwack@tweag.io> An "Sebastian Graf" mailto:sgraf1337@gmail.com> Cc "Adam Gundry" mailto:adam@well-typed.com>; ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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 mailto:sgraf1337@gmail.com> wrote:

Dear Committee,

I vote accept on this very small clarifying amendment.

Cheers, Sebastian

------ Originalnachricht ------ Von "Adam Gundry" mailto:adam@well-typed.com> An ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- -- Matthías Páll Gissurarson http://mpg.is/

Sebastian Graf

21 Nov 21 Nov

5:53 a.m.

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@mpg.is>:

...

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

Accept.

On Sun, 17 Nov 2024 at 17:26, Eric Seidel wrote:

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

...
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 mailto:simon.peytonjones@gmail.com> wrote:

Looks fine to me. I support.

Simon

On Mon, 11 Nov 2024 at 09:48, Sebastian Graf < sgraf1337@gmail.com mailto:sgraf1337@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,

On Tue, Nov 12, 2024, at 16:28, Malte Ott wrote: 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" mailto:arnaud.spiwack@tweag.io> An "Sebastian Graf" mailto:sgraf1337@gmail.com> Cc "Adam Gundry" mailto:adam@well-typed.com>; ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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 mailto:sgraf1337@gmail.com> wrote:

Dear Committee,

I vote accept on this very small clarifying amendment.

Cheers, Sebastian

------ Originalnachricht ------ Von "Adam Gundry" mailto:adam@well-typed.com> An ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

6:19 a.m.

For a small non-controversial proposal, 9 votes is plenty. Merge! Simon On Thu, 21 Nov 2024 at 10:53, Sebastian Graf 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@mpg.is>:

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

Accept.

On Sun, 17 Nov 2024 at 17:26, Eric Seidel wrote:

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

...
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 mailto:simon.peytonjones@gmail.com> wrote:

Looks fine to me. I support.

Simon

On Mon, 11 Nov 2024 at 09:48, Sebastian Graf < sgraf1337@gmail.com mailto:sgraf1337@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,

On Tue, Nov 12, 2024, at 16:28, Malte Ott wrote: 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" mailto:arnaud.spiwack@tweag.io> An "Sebastian Graf" mailto:sgraf1337@gmail.com> Cc "Adam Gundry" mailto:adam@well-typed.com>; ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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 > mailto:sgraf1337@gmail.com> wrote: > > Dear Committee, > > I vote accept on this very small clarifying amendment. > > Cheers, > Sebastian > > > ------ Originalnachricht ------ > Von "Adam Gundry" mailto:adam@well-typed.com> > An ghc-steering-committee@haskell.org > mailto:ghc-steering-committee@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@haskell.org > mailto:ghc-steering-committee@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@haskell.org > mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@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@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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Sebastian Graf

6:59 a.m.

Then I declare this proposal accepted by the committee. Am Do., 21. Nov. 2024 um 12:19 Uhr schrieb Simon Peyton Jones < simon.peytonjones@gmail.com>:

...

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

Simon

On Thu, 21 Nov 2024 at 10:53, Sebastian Graf 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@mpg.is>:

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

Accept.

On Sun, 17 Nov 2024 at 17:26, Eric Seidel wrote:

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

...
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 > mailto:simon.peytonjones@gmail.com> > wrote: > > Looks fine to me. I support. > > Simon > > On Mon, 11 Nov 2024 at 09:48, Sebastian Graf < sgraf1337@gmail.com > mailto:sgraf1337@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,

...
...
> 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" mailto:arnaud.spiwack@tweag.io> > An "Sebastian Graf" mailto:sgraf1337@gmail.com> > Cc "Adam Gundry" mailto:adam@well-typed.com>; > ghc-steering-committee@haskell.org > mailto:ghc-steering-committee@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

...
...
> > 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 > > mailto:sgraf1337@gmail.com> wrote: > > > > Dear Committee, > > > > I vote accept on this very small clarifying amendment. > > > > Cheers, > > Sebastian > > > > > > ------ Originalnachricht ------ > > Von "Adam Gundry" > mailto:adam@well-typed.com> > > An ghc-steering-committee@haskell.org > > mailto:ghc-steering-committee@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

On Tue, Nov 12, 2024, at 16:28, Malte Ott wrote: the the 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@haskell.org > > mailto:ghc-steering-committee@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@haskell.org > > mailto:ghc-steering-committee@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@haskell.org > mailto:ghc-steering-committee@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@haskell.org > mailto:ghc-steering-committee@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@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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

180

Age (days ago)

190

Last active (days ago)

List overview

Download

13 comments

9 participants

participants (9)

Adam Gundry
Arnaud Spiwack
Eric Seidel
Jakob Brünker
Malte Ott
Matthías Páll Gissurarson
Moritz Angermann
Sebastian Graf
Simon Peyton Jones

Please review #680: Clarify CRLF behavior in multiline strings (amendment to #569)

tags

participants (9)