Long line string literals

[Jim Laskey]

> On May 9, 2019, at 1:29 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> Continuing from amber-spec-experts [1]:
> 
> On Thu, 9 May 2019 at 15:37, Jim Laskey <james.laskey at oracle.com> wrote:
>> - \<LineTerminator>, \<Space> and \<WhiteSpace> (white space includes LF
>>  and CR) have been proposed with various semantics for each. There is a
>>  concern that the lack of visibility for what comes after the \. Is it a
>>  space, tab, unicode white space, LF or CR? How do you tell? (?1)
> 
> All of these are currently compile errors after a slash. So why
> complicate the problem space - just allow what is needed and continue
> to disallow what is not needed.
> 
> Thus I'd suggest that only \<LineTerminator> is allowed. \<Space>,
> \<Tab> etc would remain invalid. The visibility question is then
> entirely moot - the code won't compile unless it is \<LineTerminator>.

Reasonable.

> 
>> C) \<WhiteSpace> Consume all white space (including LF and CR) up to a
>>   non-white space or end of string.
> 
> This is the closest of the options (I really dislike D and E, and A
> and B don't really work). But I disagree that one slash should consume
> multiple lines - it should only merge two lines. How about an option
> F:
> 
> F) \<LineTerminator> Consume the line terminator and all subsequent
> whitespace until the next non-whitespace, line terminator or end of
> string.
> 
> No confusion over invisible whitespace after the slash - unless it is
> a line terminator it does not compile. No consuming multiple lines -
> the slash simply acts like a line continuation character to the next
> line. Works on single and multi line literals.

Mostly reasonable.

> 
> However, I do believe this needs to occur before auto-alignment. Since
> the user model is that of a continuation character, you'd expect the
> line below to be added to the current line before other processing
> occurs. I wouldn't expect the line below to be used in auto-alignment
> calculations. So, you'd have to accept either a two part escape
> processing, or treating \<LineTerminator> more like a unicode escape
> (ie. processed much earlier and valid everywhere except comments).
> 

This is only a problem if the continuing line is interferes with the indentation
algorithm. But that is true of any lines, so why is a continuation special?
I think we can keep the continuation as part of normal escape handling.

> thanks
> Stephen
> 
> [1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-May/001288.html