Chapel: Support Multi-Line string literals

[buddha314]

As in this ticket it would be great to support Python-like multi-line strings. This is extremely helpful when using SQL commands, for instance.

// Create  a SQL command
q = """
SELECT
  t.language
, SUM(t.awesomes) AS awesomeness 
FROM
  survey_data.language_awesomes t
WHERE
  t.language <> '{lang}'
GROUP BY 
  t.language
ORDER BY 2 DESC
LIMIT 10;
"""

Then I can use cursor.query(q.format(lang='Prolog')). THough I'm suddenly not sure if format is what I want...

[bradcray]

@daviditen : I don't know if you and Ben identified something on Brian's list for you to look at, but this one feels like low-hanging fruit from an implementation perspective. That said, we should start by getting more eyes on a specific proposal (whether this one or an alternate one) to make sure there's agreement about going ahead with the feature before putting too much effort into the implementation.

Personally, I've become convinced (over on issue #6697) that some sort of way of having a multi-line string with no need for special per-line separators (backslashes, open/close quotes, pluses, etc.) is a powerful/important feature. I feel less invested in any specific way of denoting such a string (and it might be worth a quick survey to see what our favorite languages do in this regard, if anything).

[buddha314]

For planning purposes, I'm wondering if addressing this ticket feels imminent on the Chapel side. E.g., do you think it will get done in the next 5-10 working days? I will shuffle my own stuff around accordingly.

FWIW My favorite language for this is Python. I put in an example above.

[daviditen]

Yes, I expect to work on this in the near term.

[bradcray]

I think the long pole in the tent on this one is deciding to design and agree upon the language change. If the decision were made today, the implementation should come together very quickly.

[buddha314]

Does it get submitted the house or the senate first?

Sent from my Verizon, Samsung Galaxy smartphone

-------- Original message --------
From: Brad Chamberlain [e-mail]
Date: 1/11/18 11:57 AM (GMT-08:00)
To: chapel-lang/chapel [e-mail]
Cc: Brian Dolan [e-mail], Author [e-mail]
Subject: Re: [chapel-lang/chapel] Support Multi-Line string literals (#7867)

I think the long pole in the tent on this one is deciding to design and agree upon the language change. If the decision were made today, the implementation should come together very quickly.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/chapel-lang/chapel/issues/7867#issuecomment-357043609, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAmeqSA3CjbqgwCDLBcyrxq_5rmlvizlks5tJme0gaJpZM4QsFyw.

[daviditen]

Here are some examples of ways other languages do multi-line strings. IMO the Julia/Python way seems nicest out of these examples.

D, Rust - allow normal strings to span lines

"multi
line
string"

Julia, Python - triple quotes

"""multi
line
string"""

bash, perl - Here-documents

my $message = <<'END_MESSAGE';
multi
line
string
END_MESSAGE

[buddha314]

If your "favorite languages" include Perl, you don't get a vote.

[ben-albrecht]

I believe Julia and Python use """ as a syntax to enable parsing multi-line strings, since they rely on newlines to determine when a statement ends. Being semi-colon-punctuated language, the D / Rust approach seems more appropriate for Chapel.

[bradcray]

• Swift also seems to use triple quotes.
• Go seems to use a "raw quote" (backquote)

I could imagine departing from D / Rust in spite of the fact that we use semicolons on the arguments that (a) we're more likely to be courting Python programmers than D / Rust and (b) C programmers wouldn't think/know to do this. But I'm open to arguments that the D / Rust approach is preferable.

[noakesmichael]

Preface: I know next to nothing about Julia/Python/D/Rust and less than that about bash/perl.

A naive reader of this thread, i.e. me, might imagine that the only difference between Julia/Python
and D/Rust is the number of double quotes used. Is that right? I have a hard time being
interested in this distinction.

For me, the big question is how leading/trailing whitespace is handled. I am inclined to agree
that C's answer to multi-line strings is less readable for long blocks of text than these newer
languages but it's clear where all the white space is. Do any of the exemplars have differing
answers to this?

[bradcray]

I was going to ask about leading space as well. My impression is that most of the modern approaches that we're basing this feature on preserve whitespace in order to support cutting and pasting a file into the middle of your code without making any modifications to it, which I think is the motivating scenario for @buddha314 and the "aha!" moment for me in opening up to this proposal. In cases where one wanted a multi-line string, was willing to edit the lines rather than cut-and-paste wholesale, and wanted strict control over whitespace, I think our preferred solution continues to be:

var str = "this string " +
               "spans multiple " +
               "lines";

which is equivalent to "this string spans multiple lines". In contrast, in this proposal, I believe that:

var myOtherStr = """this string
  spans multiple
    lines""";

would be equivalent to "this string\n spans multiple\n lines".

There's also a question of what seemingly escaped characters like \n mean in this tripe-quote string context, but I'm a little nervous to bring that up just yet. I believe the typical approach is to not interpret them as escapes, again on the argument that you're grabbing literal text.

[mppf]

I don't mean to distract, but while we're talking about string literals, there's also some need for a "raw" string literal (or at least something that makes it easier to write things like \s in a Regular Expression - right now you have to write \\s which isn't so intuitive).

[mppf]

Oh yeah - my previous comment is more relevant than I initially anticipated, because the different precedent languages differ in how the handle \ escapes. E.g. in a bash/Perl "Here Document", I believe that \ need not be escaped to \\ the way it is escaped within ". But in Python """ strings, \ still escapes. (But Python has a more generous intepretation of "\s" than we do - it ends up meaning the same as "\\s" - which addresses the Regular Expression issue in many cases).

[buddha314]

The whole "\\s" thing is a constant nuisance in Java as well. Are there alternatives for that?

[bradcray]

there's also some need for a "raw" string literal (or at least something that makes it easier to write things like \s in a Regular Expression

If I haven't mischaracterized how """ works in other languages, wouldn't you be able to get a raw string like you want simply by using """\s"""? (Note that this would also be a reason to use triple quotes in spite of being a semicolon-based language... It would mean "literally grab the characters that follow, including whitespace, linefeeds, etc.)

[mppf]

https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals

Python uses r"\s" for "Raw string" - meaning don't do \ escaping. Triple-quoting has no effect on \ handling. (Just type in """\n""" into a Python interpreter - and you get '\n' back but not '\\n'). BTW Python also supports the C-style adjacent string literals are combined thing.

https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation

[bradcray]

OK. In spite of my misunderstanding, it still seems to me as though triple quoting might be a reasonable way to represent strings in which backslashes aren't interpreted as escaped characters. If you're cutting and pasting a file into a multi-line triple-quoted string and the file contains the characters \ and n next to one another, it seems more likely that that cut-and-pasted file would want the two characters rather than the one linefeed (given that it contains linefeeds as well).

OTOH, it would mean diverging from Python in this regard, which could be a point of confusion. Still my intuition is that treating that sequence as two characters would be more consistent in this context.

[daviditen]

On spacing - Julia removes leading spaces so the least indented line (apparently not including the first line with the opening quotes) starts in the first column. If the line with the leading quotes only contains a newline character it is removed. Python doesn't do this de-indenting or removal of the first newline.

"""
  this string
  spans multiple
  lines"""

is

"this string\nspans multiple\nlines"

because all lines have equal spacing and so the spaces are stripped.

But

"""
  this string
  spans multiple
  lines
"""

is

"  this string\n  spans multiple\n  lines\n"

because the ending quotes are in the first column instead of having two leading spaces.

This allows you to indent quoted code at the level of the non-quoted code, but have the least-indented character be in column 1 in the resulting string. I prefer not doing this and leaving the literal spacing there like Python does.

[daviditen]

Both Python and Julia interpret escapes in triple-quoted strings.
Python:

>>> len("""\n""")
1

Julia:

julia> length("""\n""")
0
julia> length("""
\n""")
1

(The first string is empty because Julia throws away a leading newline).

Despite Julia and Python agreeing on interpreting escapes, my intuition agrees with @bradcray to not interpret them.

[mppf]

There's also C++11, which has a string literal syntax that allows arbitrary delimiters (like a Here Document in some ways).

http://en.cppreference.com/w/cpp/language/string_literal

From that page:

const char* s1 = R"foo(
Hello
World
)foo";
//same as
const char* s2 = "\nHello\nWorld\n";
 ```

Which arguably makes the basic C++ answer 

"( bla bla bla
bla bla bla)"
```

[mppf]

@daviditen - then it won't be possible to create a triple-quoted-string containing """.

[bradcray]

@mppf: If we permit both styles of quoting (as we do for normal strings, then you presumably could using '''"""'''. However, you might have a hard time making a single triple-quoted string that supports both triple single quotes and triple double quotes. At which point maybe your solution is to go back to normal strings.

[ronawho]

👍 for python style """ """ quotes

[mppf]

My current preference is that we should support two (or more) string delimiters that differ in how escaping works inside the string. Then, I think we should support multi-line strings across all of the string literals.

e.g.

"multi
line
string"

""" raw
multi
line string \n
"""

where the n in the """ would translate to the same as "\\n".

(Edit: The reason for this preference is that I'm having trouble justifying the error message for multi-line string literals when it could just as well be an error for an unterminated string literal).

[ben-albrecht]

This allows you to indent quoted code at the level of the non-quoted code, but have the least-indented character be in column 1 in the resulting string. I prefer not doing this and leaving the literal spacing there like Python does.

@daviditen - do you know of any downsides with Julia's multi-line string approach? I have no experience with it, but it sounds really appealing. I've found the Python style ugly at times when I have a multi-line string that's not on the outermost scope, e.g.

def usage():

    print(
        """
Usage examples:

Test deployment:
       $ fab [noinput] test deploy

Staging deployment:
       $ fab [noinput] staging deploy

Production deployment:
       $ fab [noinput] production deploy
""")

would look nicer as:

def usage():

    print(
        """
        Usage examples:
        Test deployment:
            $ fab [noinput] test deploy
        Staging deployment:
            $ fab [noinput] staging deploy
        Production deployment:
            $ fab [noinput] production deploy
        """
    )

This was taken from this post, but there are a number of example within our repository's python code as well.

Python users can get around this issue by post-processing the multi-line strings with the textwrap module or a trim function, whereas Julia's implementation eliminates the issue altogether. That said, I am not familiar with issues that Julia's multi-line strings may suffer from.

[vasslitvinov]

• I prefer not to post-process strings (ex. adjust indentation) within triple quotes, on grounds of simplicity. To me simplicity outweighs the beauty benefits that BenA mentions above.

• Not handling backslashes within triple quotes is better for cutting and pasting. If the user needs backquoting, they can use single-quote strings for those pieces (as Brad suggests above) and then "+" the pieces together.

• To allow both triple-single-quotes and triple-double-quotes within one string, my ideal solution is a user-definable delimiter, allowing it to be a multi-character string. Bash's here-documents are essentially that. (We do not have to use bash syntax.) We can leave this feature as future work.

[bradcray]

👍 for python style """ """ quotes

I agree, but given that Chapel permits strings to be delimited with either single or double quotes ("my string" or 'my string') I think we should do the same for triple quote strings (support triple single quote in addition to triple double quote).

Then, I think we should support multi-line strings across all of the string literals.

I'd be curious for @dmk42 to weigh in on this. Specifically, I believe C doesn't permit string literals to extend across lines. Was there a rationale for this? Does it apply to Chapel?

(Guessing, I could imagine that in a string literal where backslashes were interpreted as escapes it could be much more confusing to potentially not close a string that you thought you had due to mis-application of backslashes. For that reason alone, I wouldn't object to not extending Chapel's current strings to support multi-line. It also gets away from a funny question about "What do the newlines mean in a plain-old string?").

[dmk42]

@bradcray - You are correct that C does not permit multiline string literals. This was done to avoid having any tokens other than comments span lines. In other words, it was for ease of parsing rather than anything related to how it would be used. This would not apply to Chapel.

There are two ways to achieve something similar in C, neither of which would solve the problem being presented here.

1. A backslash-newline sequence is deleted before tokens are even recognized, so it allows one string literal to span multiple physical lines, but the newline isn't included in the result. This would not be useful for cutting and pasting text into a program without further modification.

"string \
literal"
becomes
"string literal"

1. Adjacent string literal tokens are concatenated to form one string literal. This also would not help with cut-and-paste.

"string "
"literal"
becomes
"string literal"

[bradcray]

There are two ways to achieve something similar in C...

To me, these two approaches hearken back to discussions in PR #5497 / issue #5501 where we effectively decided that Chapel's current support for

"string " +
"literal" 

was effectively as good as any other approach that requires editing lines to split them across multiple code lines without introducing newlines (so decided not to support other ways of doing so.

Your high-level comment about Chapel not needing to be guided by C in this regard suggests to me that Michael's proposal that we support two string types (interpreted and non-interpreted) and permit each to support multiple lines is reasonable. Intuitively, I'd probably still keep current strings single-line only, and non-interpreted strings multi-line, but I'm definitely open to being talked out of it given your feedback.

[dmk42]

I agree that Chapel's current feature set is sufficient for cases where it is OK to require the lines to be edited.

I also agree that it would be good to have a non-interpreted string type, and it seems cleaner to me to have interpreted strings be single-line only. This is essentially what C++ has done.

It doesn't matter to me how non-interpreted strings are delimited, whether triple quotes, or C++'s arbitrary delimiters, or something else.

[buddha314]

In the "non-interpreted, multi-line" version, would one be able to do

var q =

SELECT {%s} FROM {%s} LIMIT 10;

Then use

writeln(q.format("dinner", "table"));

for variable substitution?

[dmk42]

I don't see any reason that shouldn't work. The type of the string would not be different, only the spelling of its contents would be affected.

[buddha314]

Actually, I should have made the example multi-line. Just making sure I can do variable substitution on

SELECT
  a_column
, another_column
FROM
  {%s}
WHERE
  {%s} = {%s};

[dmk42]

There is no reason that should present a problem.

[daviditen]

Do you know of any downsides with Julia's multi-line string approach?

I've only played with it a bit, but getting things lined up the way you want them takes some practice and is pretty confusing. There's also some weirdness with the indentation of the first line being ignored.

print("""first
             second
             third""")

first
second
third

[ronawho]

👍 for python style """ """ quotes

I agree, but given that Chapel permits strings to be delimited with either single or double quotes ("my string" or 'my string') I think we should do the same for triple quote strings (support triple single quote in addition to triple double quote).

Python also has single and double quote delimited strings (and supports either """ """ or ''' '''), so I really meant +1 for python style multi-line strings

[bradcray]

Do you know of any downsides with Julia's multi-line string approach?

I've only played with it a bit, but getting things lined up the way you want them takes some
practice and is pretty confusing.

In a Julia-like approach, if you wanted each line of your string to start with whitespace, is there a way to get that?

My intuition, which comes with no experience using multi-line strings in Julia or Python, is that multi-line strings are going to be somewhat of a discontinuity in the program text regardless of what we do, and so I'm inclined not to make things more complex / surprising by doing special things with leading whitespace (other than "make them part of the string"). As with my previous comment, this is something I'm willing to be convinced I'm wrong about, though.

[dmk42]

Just a personal preference, I don't like the idea of having any interpreted characters at all inside a non-interpreted string. That includes spaces.

[daviditen]

In a Julia-like approach, if you wanted each line of your string to start with whitespace, is there a way to get that?

As far as I can tell, the string needs to end with a newline so the closing quote can be the least indented thing to let everything else be indented. The final newline is included in the string:

print("""
  first
  second
  third
""")

[bradcray]

Just a personal preference, I don't like the idea of having any interpreted characters at all inside a non-interpreted string. That includes spaces.

So if Michael's vision of "all strings support multiple lines" went forward, we could support Julia-like behavior w.r.t. leading whitespace for the interpreted case (single quotes) and suck in the whitespace for the non-interpreted (triple quotes) case.

Downsides: increased implementation complexity / Brad's intuition about keeping uninterpreted strings to a single line is abandoned.
Upsides: programmers can have whichever kind of leading space behavior they want.

[ben-albrecht]

Based on the description in Julia's documentation, I expected @daviditen's example to properly indent. I suspect there is an error in their documentation or implementation. Here are some other ways to write the same print statement in Julia:

println("""
        first
          second
          third
        """)

println("""
        first
          second
          third""")


println("""first
          second
          third
        """)

multi-line strings are going to be somewhat of a discontinuity in the program text regardless of what we do

Maybe so, but maintaining indentation can make that discontinuity slightly less clashing, e.g.

module Greetings {
  proc hello() {
    writeln("""
            hello
              world
            """);
  }
}

// vs.

module Greetings {
  proc hello() {
    writeln("""
hello
  world
            """);
  }
}

[bradcray]

Maybe so, but maintaining indentation can make that discontinuity slightly
less clashing,

The example in your response doesn't feel realistic / compelling to me. In the case of cutting and pasting a file into the source (which was the original motivation for this issue), it's challenging for me to believe that a user would be unwilling to add quotes and pluses (either manually or through scripting) but would be willing to indent the file in a certain way to make it look good. Conversely, if the user does want to modify the file's contents to make the source look good (as in the example you show), it seems like requiring them to add quotes and pluses isn't all that awful, and in fact looks better/clearer while raising less questions about what happens to leading whitespace.

[daviditen]

The discussion in this Julia issue that was opened in response to a question @ben-albrecht asked on stackoverflow makes me think that the leading whitespace removal causes more confusion than it is worth.

I propose that we use """ and ''' as delimiters for strings that are not interpreted and allow newlines. I'm open to letting interpreted strings have newlines, but I think that can be a separate question. I'm not a fan of the leading whitespace removal in either case.

[ben-albrecht]

@bradcray :

The example in your response doesn't feel realistic / compelling to me. In the case of cutting and pasting a file into the source (which was the original motivation for this issue), it's challenging for me to believe that a user would be unwilling to add quotes and pluses (either manually or through scripting) but would be willing to indent the file in a certain way to make it look good.

Here's a more realistic example combining code from a numsuch with @buddha314's earlier example. I don't think the indented text block is much of a discontinuity, whereas the second example certainly is.

proc vNamesFromPG(con: Connection, nameTable: string.
                  nameField: string, idField: string ) {

  var cursor = con.cursor();
  var q1 = """
           SELECT
             a_column
           , another_column
           FROM
             {%s}
           WHERE
             {%s} = {%s};
           """;
  cursor.query(q1, (idField, nameTable));
  var n:int= cursor.fetchone()['n']: int;
  var vertexNames: [1..n] string;

  var q2 = "SELECT %s, %s FROM %s ORDER BY 1";
  cursor.query(q2, (idField, nameField, nameTable));
  for row in cursor {
      vertexNames[row[idField]:int ] = row[nameField];
  }
  return vertexNames;
}

vs.

proc vNamesFromPG(con: Connection, nameTable: string.
                  nameField: string, idField: string ) {

  var cursor = con.cursor();
  var q1 = """
SELECT
  a_column
, another_column
FROM
  {%s}
WHERE
  {%s} = {%s};
""";
  cursor.query(q1, (idField, nameTable));
  var n:int= cursor.fetchone()['n']: int;
  var vertexNames: [1..n] string;

  var q2 = "SELECT %s, %s FROM %s ORDER BY 1";
  cursor.query(q2, (idField, nameField, nameTable));
  for row in cursor {
      vertexNames[row[idField]:int ] = row[nameField];
  }
  return vertexNames;
}

@daviditen :

The discussion in this Julia issue that was opened in response to a question @ben-albrecht asked on stackoverflow makes me think that the leading whitespace removal causes more confusion than it is worth.

This does make me reconsider following exactly in their path. Maybe it's worth exploring a simpler set of rules or an explicit way to opt into dedenting.

[bradcray]

Here's a more realistic example

Would the inclusion of the leading whitespace in the indented case break the query in some way? (i.e., is the query syntax whitespace sensitive and intolerant of leading whitespace?)

Is this a case that would not want to be written with "" + for some reason? (i.e., It doesn't look like a case where a pre-existing file was cut-and-pasted into the source...).

[ben-albrecht]

Would the inclusion of the leading whitespace in the indented case break the query in some way? (i.e., is the query syntax whitespace sensitive and intolerant of leading whitespace?)

Not sure, but let's assume that it does so I don't have to mock up another example where it does matter :)

Is this a case that would not want to be written with "" + for some reason? (i.e., It doesn't look like a case where a pre-existing file was cut-and-pasted into the source...).

I considered including that example, but decided it was too much effort to write out, which is a point in itself... I think multi-line strings are valuable outside of cut-and-pasting text into a source file. It can reduce the effort in reading, writing, and refactoring multi-line strings.

[bradcray]

Not sure, but let's assume that it does so I don't have to mock up another example where it does matter :)

It seems more likely to me that it doesn't matter because if it did, it probably wouldn't be OK with newline characters appearing between every argument either (?). My point in asking is: if the leading whitespace doesn't matter in the string than nothing about taking the simpler language design that David's proposing would prevent you from writing it the way you want (i.e., you can indent it as you like and don't need that leading whitespace to be trimmed).

I think multi-line strings are valuable outside of cut-and-pasting text into a source file. It can reduce the effort in reading, writing, and refactoring multi-line strings.

That's fair, but I think we've already effectively decided to support multi-line strings so I'm not arguing against that. The question here is whether we also need to add complex "strip leading whitespace" rules to them. So far, I'm still thinking "no, we don't."

[bradcray]

Even if we did come up with a compelling case that really wanted to both (i) indent a multi-line string literal and (ii) strip that leading indentation off... rather than making the lexer/language more complicated, we could instead take the approach of having a library routine that stripped leading whitespace from each line of a (param?) string equal to (a) the first/second line's leading whitespace, (b) the min amount of leading whitespace on any line, and/or (c) a user-specified value. This would arguably also more explicit in the source code than trying to understand/memorize Julia-like rules.

[ben-albrecht]

My point in asking is: if the leading whitespace doesn't matter in the string than nothing about taking the simpler language design that David's proposing would prevent you from writing it the way you want

Agreed, I am only concerned about cases where leading space would matter. As an example, the above program could print the queries when a debug flag is thrown - we wouldn't want the leading whitespace going to stdout in these cases.

That's fair, but I think we've already effectively decided to support multi-line strings so I'm not arguing against that. The question here is whether we also need to add complex "strip leading whitespace" rules to them.

I was trying to address the implication from your original comment that multi-line strings are only useful for cases where text is cut-and-pasted into a source file.

Thinking more on this, an opt-in solution to this problem seems like a good route. Keeping the base language rules simple is appealing and I think we could do better than Python with something like secondary methods:

```chpl
use TextWrap; // Borrowing Python's module name for example

module MatrixOps {
// ...
proc vNamesFromPG(con: Connection, nameTable: string.
nameField: string, idField: string ) {

var cursor = con.cursor();
var q1 = """
         SELECT
           a_column
         , another_column
           FROM
           {%s}
         WHERE
           {%s} = {%s};
         """;
q1 = q1.dedent(); // string.dedent() defined in TextWrap module
// ...

}
}
```

edit: did not see your latest comment when writing this - seems like we are converging on the same idea though.

[buddha314]

I have to say I aesthetically prefer trimming leading whitespace and I feel I should side with Ben on this one, but I'm having a hard time finding the definitive use case.

[buddha314]

And additionally I am suffering right now from not having multi-line strings. Creating pain in another window as we speak.

[bradcray]

And additionally I am suffering right now from not having multi-line strings. Creating pain in another window as we speak.

Every time a user whines, we add another day to the delivery of a new feature!

Seriously, though, I wonder whether @daviditen's exploratory branch is far enough along for you to experiment with already...?

[daviditen]

I like the idea of having a library routine to do the indentation removal - especially if it also works on params.

[daviditen]

I just launched a linux64 paratest run against my branch. I don't anticipate any surprises in the testing, but be advised that it hasn't been fully tested yet. It implements what I proposed we go with ~3 hours ago. Feel free to try it out.

https://github.com/daviditen/chapel/tree/triple-quote-string

It includes a test/demo of what they do:
uninterpretedMultilineString.chpl

[buddha314]

Do you think it will hit master by about midnight PT? That's probably when I can try it next.

[daviditen]

Do you think it will hit master by about midnight PT? That's probably when I can try it next.

No, sorry. It can't go into master until we've converged on the design. If you'd like to try it out you'll have to do it from my branch for now.

[daviditen]

The testing I kicked off for the triple-quote-string branch last night passed as expected:

[Test Summary - 180117.174751]
[Summary: #Successes = 8186 | #Failures = 0 | #Futures = 0]

[daviditen]

After more group discussions we've decided that we will use """ and ''' as delimiters for strings that are not interpreted and allow newlines. They will not remove leading whitespace, but we plan to provide functions to handle that. This is what my branch linked above does, and I believe it is ready to be reviewed and then merged.

Issue #8280 is about multi-line "traditional/interpreted" strings, including the question of whether they should strip leading space.

Issue #8281 requests the library functions to strip leading whitespace.

[ben-albrecht]

Sorry to mention after the merge, but I want to clarify:

Based on the current decision, which ties multi-line strings and uninterpreted strings together, users lose the ability to write multi-line interpreted strings. I don't know if this was ever explicitly called out in the discussion. Are we OK with this?

[daviditen]

I don't think users lost anything - they never had the ability to write multi-line interpreted strings. Issue #8280 was opened to discuss multi-line interpreted strings.

[buddha314]

Are there plans to document how to use it? I could literally use it right now. Is it in master?

[mppf]

Are there plans to document how to use it? I could literally use it right now. Is it in master?

yes it's just landed and you just use """ bla bla bla """. \n etc will not turn into newlines, they will stay backslashed.

[bradcray]

To @buddha314's question about documentation, I was curious about the same thing and was happy to see that the spec was updated in the PR to document the new capability: https://github.com/chapel-lang/chapel/pull/8282/files#diff-d482ef22b7b571e13d5d3ed22b373cb7

[edited to fix original link]

[buddha314]

It supports typos in the word "blah"? What about

"""
blah
blah
  dee
blah
"""

[bradcray]

@buddha314 : That should be equivalent to "\nblah\nblah\n dee\nblah\n" in a traditional / interpreted string. (I.e., your whitespace will be preserved).

[daviditen]

If you'd prefer to see how it works by example instead of by reading the spec, the test case included in the PR is a pretty good example.

[buddha314]

the test case included in the PR is a pretty good example.

I admire your ability to be impartial. This looks absolutely perfect, trying it today. Thanks!