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

[Jakob Brünker]

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>