Raw strings starting/ending with backtick

[Cay Horstmann]

Le 26/11/2018 à 10:20, John Rose a écrit :
> On Nov 26, 2018, at 1:05 AM, Cay Horstmann <cay.horstmann at sjsu.edu 
> <mailto: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/.

Yes.

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

No, that was not what I intended. Any sequence m * Q, where m ≥ n, would 
close, with (m - n) * Q belonging to s.

I thought that was how it had to be. How else can you parse raw strings 
ending in backticks? But I just realized that is not how it works in 
12-ea. I misunderstood how your closing quotes work. Would it be hard on 
the parser to do it my way?

> 3. After the R, you surely want the ability to strip some horizontal 
> space also.

No.

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

I am aware of the "align" methods. Now those have sharp edges. Of course 
aligning problems can be avoided by placing the string at the leftmost 
column, like I have done in my example. This is why R = /\s*\n/ is a 
good choice.

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

See above.

Cheers,

Cay


-- 

Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com