[ghc-steering-committee] Please review #680: Clarify CRLF behavior in multiline strings (amendment to #569)
Eric Seidel
eric at seidel.io
Sun Nov 17 16:26:37 UTC 2024
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
More information about the ghc-steering-committee
mailing list