Long line string literals

[Stephen Colebourne]

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>.

> 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.

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).

thanks
Stephen

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