I'm pretty agnostic on the whitespace-stripping details here. I think Haskellers will learn to deal with whatever is decided, so I think the choice is pretty low stakes. On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes. Yet I don't want the perfect to become the enemy of the good, so I vote for acceptance. Richard

On Dec 27, 2023, at 2:23 PM, Eric Seidel wrote:

Dear Committee,

Brandon Chinn has proposed[1] adding multi-line strings to Haskell. Most languages these days support multi-line strings, even Java has them as of Java 17 (which coincidentally is a strong inspiration for Brandon's proposal). Yet in Haskell we have to resort to tricks like `unlines` or quasiquoters.

Brandon's proposal adds support for triple-quote delimited multi-line strings, e.g.

``` adtParseJSON = """ \\v -> case v of Aeson.Null -> pure PrintStyleInherit Aeson.String "" -> pure PrintStyleInherit _ -> PrintStyleOverride <$> Aeson.parseJSON v """ ```

The rules are largely inspired by Java's text blocks[2] proposal, which I've also read and find very pragmatic. Honestly, I encourage the Committee to read the Java proposal as well. Haskell innovates in many areas of language design, but the lexical structure of strings feels like an area where we should conserve our innovation tokens. Brandon's proposal does a great job here of starting from an established baseline and adapting it to Haskell's idiosyncrasies.

One point I would draw the Committee's attention to is the handling of characters on the opening line[3]. My only concern with this proposal is that omitting the opening line from the prefix calculation can lead to some counterintuitive behavior. For example

``` s = """ foo bar """ ```

would be parsed as `" foo\nbar"`. I'm on the fence about whether we should try to be more prescriptive here, or just expect that Haskeller's will learn to avoid this corner case. I think it's probably fine.

On balance I think we should accept the proposal.

Thanks! Eric

[1]: https://github.com/ghc-proposals/ghc-proposals/pull/569 [2]: https://openjdk.org/jeps/378 [3]: https://github.com/brandonchinn178/ghc-proposals/blob/multiline-strings/prop... _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Yes that's true of course, but if we had a design that could cover raw strings as well, then we have one fewer quoting construct. I guess the real question is: do we need the ability to toggle between multiline and raw separately? That is, right now we have cooked single-line strings. This proposal is for cooked multiline strings, leaving raw strings for a separate proposal. But maybe we only need cooked single-line strings and raw multiline ones? That would be simpler. I think wisdom from other languages would be helpful here. I will post on the ticket. Richard

On Dec 31, 2023, at 12:04 PM, Eric Seidel wrote:

...

On Dec 29, 2023, at 07:19, Richard Eisenberg wrote:

On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes.

I had a similar thought at first, but I think raw strings can be added independently of this proposal. So long as we are not closing the door to a future addition I think it is fine to take incremental steps.

I’m generally in favor of this! Do we consider this experimental or stable? Does the author intent to make breaking changes without or with warning/deprecation cycles? Do we expect to see changes based on community feedback once this is available in some form to the working developer? Cheers, Moritz On Sun, 31 Dec 2023 at 6:40 AM, Joachim Breitner wrote:

Hi,

thanks for the good analysis and recommendation, happy to follow suit. The color of the shed is less important than that the bikes stay dry.

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