Re: String reboot - (1a) incidental whitespace

Good points. Like I said, I think we are in agreement! —Guy > On Apr 22, 2019, at 8:00 PM, Alex Buckley wrote: > > On 4/22/2019 12:16 PM, Guy Steele wrote: >>> On Apr 22, 2019, at 3:04 PM, Alex Buckley >>> wrote: >>> >>> Nope, I don't think multi-line string literals are an attractive >>>

Re: String reboot - (1a) incidental whitespace

On 4/22/2019 12:16 PM, Guy Steele wrote: On Apr 22, 2019, at 3:04 PM, Alex Buckley wrote: Nope, I don't think multi-line string literals are an attractive nuisance in any way. We should NOT deem it incorrect to refactor a sequence of concatenations into a single multi-line string literal. I

Re: String reboot - (1a) incidental whitespace

That's an interesting use case: The original string expression is multi-line, but all of the line terminators are in the envelope, not the payload. If I were writing this as a single literal in Bourne shell I might consider using a formulation that breaks the long line into several smaller

Re: String reboot - (1a) incidental whitespace

So is your point that multiline string literals may be an “attractive nuisance” in that they may make it too convenient for inattentive programmers to perform _incorrect_ refactoring? > On Apr 19, 2019, at 8:16 PM, Alex Buckley wrote: > >> On 4/10/2019 8:22 AM, Jim Laskey wrote: >> Line

Re: String reboot - (1a) incidental whitespace

On 4/10/2019 8:22 AM, Jim Laskey wrote: Line terminators: When strings span lines, they do so using the line terminators present in the source file, which may vary depending on what operating system the file was authored. Should this be an aspect of multi-line-ness, or should we normalize

Re: String reboot - (1a) incidental whitespace

> On Apr 19, 2019, at 2:09 PM, Liam Miller-Cushon wrote: > > . . . > Maybe more interesting is that the both following work as an alternative > pattern; > > String m = """I won’t > get any alignment > (except maybe NL normalization) >

Re: String reboot - (1a) incidental whitespace

Not sure I understand the issue here. The first line has no influence and is not affected by the indentation provided by the close delimiter influence. The example is a bit groggy. Maybe more interesting is that the both following work as an alternative pattern; String m = """I won’t

Re: String reboot - (1a) incidental whitespace

> On Apr 18, 2019, at 7:55 PM, John Rose wrote: > . . . > Also, is a left-margin quote allowed immediately before the > close-quote? Is it required? If allowed and not required, > this basically means such a string can end with either three > or four close-quotes. I would say “not allowed”.

Re: String reboot - (1a) incidental whitespace

> On Apr 18, 2019, at 8:04 PM, John Rose wrote: > . . . > One reason people hate those extra stars in comments is > that they are using an editor (like Emacs) which is pretty > good at generic indentation, but doesn't know about > language-specific left margin markup, like stars or > (in Guy's

Re: String reboot - (1a) incidental whitespace

On Apr 16, 2019, at 4:03 PM, Liam Miller-Cushon wrote: > > One disadvantage is the handling of the trailing newline. Requiring the > closing delimiter to be on its own line means there's always a trailing > newline in source. If we want to allow expressing multi-line strings that > don't have

Re: String reboot - (1a) incidental whitespace

I think your comments below ar emostly applicable to Guy's lightweight "box of quotes" proposal, where the open and close quotes are small (""") and single quotes appear (like stars in a comment) along the left margin. The "blast radius" for making edits is much smaller for the lightweight

Re: String reboot - (1a) incidental whitespace

On Apr 17, 2019, at 1:07 PM, Guy Steele wrote: > String s = “”” >""I am >" a block of text" >“””; > > You have choices. I’m not entirely sure I like such a design, but I’m > putting it out there for contemplation. Using the single quotes along

Re: String reboot - (1a) incidental whitespace

On Apr 18, 2019, at 5:24 AM, Jim Laskey wrote: > > John suggested some modifications which led to a Swiss Army trimMargin which > could handle everything you suggest and much more. In the end, what changed > our minds (Hmmm, could have been Loki the Trickster taking on my appearance.

Re: String reboot - (1a) incidental whitespace

On Apr 18, 2019, at 5:43 AM, Jim Laskey wrote: > > What kills the concept is that ODI is not reproducible in a library method. That also impacts the concept of using escapes to opt out, since the library method cannot see escapes, while the compiler can see them. I suggest the following rule:

Re: String reboot - (1a) incidental whitespace

On Apr 18, 2019, at 10:08 AM, Liam Miller-Cushon wrote: > > Putting non-blank text on that first line is effectively an opt-out +1 I think that would be a reasonable design move. It's a bit ugly but it's learnable. (Putting in \0040 for a not-to-be-stripped space is also ugly but learnable.)

Re: String reboot - (1a) incidental whitespace

On Thu, Apr 18, 2019 at 8:52 AM Brian Goetz wrote: > I still find the restriction appealing for the opening delimiter, though. > The argument is that having contents on the opening line seems likely to > cause confusion, e.g.: > > String m = """++ >

Re: String reboot - (1a) incidental whitespace

I had a prototype ready with opening delimiter influence, which worked quite well. What kills the concept is that ODI is not reproducible in a library method. How ODI works in the compiler is that it counts the number of characters in the scan buffer, starting at the start of line, leading up

Re: String reboot - (1a) incidental whitespace

I see value in this notion. Early on in the design of RSL we had a trimMargin equivalent defined in String. John suggested some modifications which led to a Swiss Army trimMargin which could handle everything you suggest and much more. In the end, what changed our minds about providing

Re: String reboot - (1a) incidental whitespace

Okay, for this message I abandon rectangles and adopt Version 2 of the algorithm, as described by Brian (see below): a trailing blank line before the final delimiter is included in computing the leading whitespace prefix. Now I return to an idea we’ve seen before: > From: Tagir Valeev > Date:

String reboot - (1a) incidental whitespace

I pushed changes to http://hg.openjdk.java.net/amber/amber string-tapas branch to reflect the incidental whitespace discussion. What is implemented is what Brian described as Version 2 of the algorithm — the “significant closing delimiter” version —

Re: String reboot - (1a) incidental whitespace

We'll try to get some numbers on the occurrence of common-leading-indentation. We can also look at how common substitute-before-parse appears to be. However, we have heavily moved toward libraries that can parse first and substitute later, because they don't suffer from injection attacks. On

Re: String reboot - (1a) incidental whitespace

Interesting idea. This pushes towards the “let the language do as much as it can”, so that such indexes are maximally useful. But I wonder if this approach is doomed to run out of gas anyway? Because, even if we do auto-alignment, so there is a single ML string literal, there is likely to be

Re: String reboot - (1a) incidental whitespace

> > I'm sorry I'm not completely caught up on this discussion yet and may have > missed something. But I'm confused what the alternative to using the closing > delimiter position is. You certainly don't want to magically use the column > position of the *opening* delimiter in this example!

Re: String reboot - (1a) incidental whitespace

> On Apr 17, 2019, at 1:56 PM, Elias N Vasylenko wrote: > . . . > One more very minor point against the box-of-quotes: believe it or not > there is a small-but-non-empty set of people who prefer programming > with proportional fonts, no matter how perverse that may seem to the > rest of us.

Re: String reboot - (1a) incidental whitespace

If we design with our preferred IDE support in mind then Guy's box-of- quotes proposal appears to be functionally equivalent to Jim's IDE- highlighted-box suggestion. Given two equivalent proposals I'd go with the one that delegates to the IDE rather than complicating the language spec. And if

Re: String reboot - (1a) incidental whitespace

> On Apr 17, 2019, at 8:55 AM, Jim Laskey wrote: > > To paraphrase McLuhan, I think that we need to keep the focus on the rider > and not the horse they rode in on. This was the main reason I pushed for > backtick over triple double quote; making it about the content and not the > syntax

Re: String reboot - (1a) incidental whitespace

(inline and at the bottom) > On Apr 16, 2019, at 8:03 PM, Liam Miller-Cushon wrote: > > On Wed, Apr 10, 2019 at 8:25 AM Jim Laskey > wrote: > Don’t peek yet. Stop and comment first. > > Here's a variation on the narrative you provided. This is more thinking

Re: String reboot - (1a) incidental whitespace

To be clear: “closing delimiter influence” means that, before we strip off that blank line, we look at how much whitespace it has, and we include that in our calculation of “common leading whitespace prefix”. (This has been called a “determining line” in prior discussions of alignment.). The

Re: String reboot - (1a) incidental whitespace

The positive aspect; having control of indentation at the literal level. > On Apr 17, 2019, at 10:13 AM, Jim Laskey wrote: > > Brian points out that we under highlighted "closing delimiter influence". > Liam eludes to it in his discussion, but I'll break the discussion out here. > > In the

Re: String reboot - (1a) incidental whitespace

Brian points out that we under highlighted "closing delimiter influence". Liam eludes to it in his discussion, but I'll break the discussion out here. In the following example I'll use "." to indicate whitespace; String s = """ ...line 1 ...line 2 ...""";

Re: String reboot - (1a) incidental whitespace

Thank you. Sent from my iPhone > On Apr 16, 2019, at 5:50 PM, Liam Miller-Cushon wrote: > >> On Fri, Apr 12, 2019 at 8:39 AM Jim Laskey wrote: > >> Do you have numbers from your RSL survey for, of all string expressions that >> are candidates for translation to a multi-line string literal,

Re: String reboot - (1a) incidental whitespace

So let's move on to the follow up question.  If you replace concatenated strings -- which can have exactly the right amount of indentation:     String s =     "public class Foo { \n" +     "    void m() { }\n" +     "}"; with multi-line strings:     String s = """     public

Re: String reboot - (1a) incidental whitespace

That's pretty encouraging; 84 out of 85 would have no escapes, and the other 1 would have the same escapes it has now. On 4/16/2019 4:50 PM, Liam Miller-Cushon wrote: On Fri, Apr 12, 2019 at 8:39 AM Jim Laskey > wrote: Do you have numbers from your RSL

Re: String reboot - (1a) incidental whitespace

> On Apr 16, 2019, at 4:02 PM, Brian Goetz wrote: > > Indeed, it does solve a number of "figure out what was the user thinking" > questions. > > You hit the nail on the head regarding IDE support. Our original thinking > was that it should be easy to cut and paste between a (say) JSON

Re: String reboot - (1a) incidental whitespace

Indeed, it does solve a number of "figure out what was the user thinking" questions. You hit the nail on the head regarding IDE support.  Our original thinking was that it should be easy to cut and paste between a (say) JSON document and a Java source program, without having to mangle it up

Re: String reboot - (1a) incidental whitespace

Actually, let me point out that the rectangle-of-double-quotes syntax is entirely compatible with Jim Laskey’s suggestions; the two can coexist. Define the rectangle-of-double-quotes syntax to be: ::= * * * where ::= * * and the meaning of such a literal is the concatenation

Re: String reboot - (1a) incidental whitespace

Just in case it wasn’t clear, I want to emphasize that my suggestion of using a rectangle-of-double-quotes was intended as a serious proposal—admittedly one that looks unusual and would require good cooperation from each IDE to be practical, but one that solves a number of the problems about

Re: String reboot - (1a) incidental whitespace

Let me extract some observations, and questions, from JIm’s mail here. I think the alignment algorithm Jim is driving towards is something like this: - Strip up to one leading and trailing blank line - Align the remaining lines by removing the largest common whitespace prefix from each [1]

Re: String reboot - (1a) incidental whitespace

Kevin & Alan, Do you have numbers from your RSL survey for, of all string expressions that are candidates for translation to a multi-line string literal, what percentage contain no escapes other than quotes and newline? Thank you, -- Jim > On Apr 10, 2019, at 12:22 PM, Jim Laskey wrote: >

Re: String reboot - (1a) incidental whitespace

It's more or less the javadoc approach no ? Rémi > De: "Guy Steele" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Mercredi 10 Avril 2019 23:36:34 > Objet: Re: String reboot - (1a) incidental whitespace >> On Apr 10, 2019, at 4:5

Re: String reboot - (1a) incidental whitespace

> On Apr 10, 2019, at 5:36 PM, Guy Steele wrote: > > >> On Apr 10, 2019, at 4:54 PM, Brian Goetz > > wrote: >> >> This is a plateful! >> >> Stripping "incidental" whitespace is an attractive target of opportunity; >> the real question is, can we do it right

Re: String reboot - (1a) incidental whitespace

> On Apr 10, 2019, at 4:54 PM, Brian Goetz wrote: > > This is a plateful! > > Stripping "incidental" whitespace is an attractive target of opportunity; the > real question is, can we do it right enough of the time, and when we get it > wrong, is there an easy way for the user to recover and

Re: String reboot - (1a) incidental whitespace

This is a plateful! Stripping "incidental" whitespace is an attractive target of opportunity; the real question is, can we do it right enough of the time, and when we get it wrong, is there an easy way for the user to recover and get what they want? Kevin described this as: "find the magic

String reboot - (1a) incidental whitespace

Next plate is (1a) incidental whitespace. Having decided that we are content with "fat" delimiters (""") for multi-line strings, we have some more choices to make regarding multi-line strings. (We're not going to talk about "raw" strings yet; let's finish the multi-line course first.)