Raw strings starting/ending with backtick

[John Rose]

On Nov 26, 2018, at 1:05 AM, Cay Horstmann <cay.horstmann at sjsu.edu> wrote:
> 
> the scheme that I suggest would, in your notation be an OQ1 scheme, with Q = '\'' and R = '\n', quoting any string s as n * Q + R + s + n * Q, with sufficiently large n. Do you recall what sharp edges one would run into? It's not intuitive to me and it would be good to learn from your experience.

Having backtick-with-whitespace as an option besides backtick-alone
basically introduces two new quoting conventions.

Also, the choice of whitespace is tricky to use in syntax because whitespace
displays ambiguously.  I'm sympathetic to using whitespace for R since it
seems to make the two quoting conventions so similar that they are seemingly
just one, with an optional tweak.  But the whitespace has downsides too:
Making a quoting convention depend on details of whitespace is asking for
puzzlers.  There are joke computer languages which depend on the distinction
between O and 0, or space and tab; we don't want to be like that.

1. You'd want to use R ~ /\s*\n/ since there's no visual difference between
that pattern and a simple /\n/.

2. The close quote would have to contain R somewhere also, which leads
to possible near-misses if the Q's are there and the R isn't.  Again, having
R be next to invisible (whitespace) makes it harder to find a bug if it happens.

3. After the R, you surely want the ability to strip some horizontal space also.
We are adding an intrinsic "align" method to handle this.  My point is that
mandating a newline causes new problems:  The user then is required
to manage horizontal space on the new line.

4. The design of the close-quote has similar sharp edges.

Making R = '|' or some other printing character, and the close-quote be RQ*,
would cause fewer problems with whitespace-related format.  But it would also
in effect introduce a second quoting convention.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181126/e856749b/attachment.html>