[ghc-steering-committee] Please review #680: Clarify CRLF behavior in multiline strings (amendment to #569)

[Sebastian Graf]

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>