Re: [PATCH] Interpret #r"..." as a raw string

[Alan Mackenzie <acm@muc.de>]

Hello, Daniel.

On Tue, Mar 02, 2021 at 01:56:43 -0800, Daniel Brooks wrote:
> Matt Armstrong <matt@rfc20.org> writes:

> > Alan Mackenzie <acm@muc.de> writes:

> > C++ has probably the most flexible "gold standard" raw string literals.

> With respect, I think that Raku “wins” this
> fight. https://docs.raku.org/language/quoting is really worth reading;
> it's a work of art. You can think of the quote operator as a function
> that takes 13 named boolean arguments plus a choice of opening and
> closing delimiters.

I haven't looked at raku, but I imagine that this "quoting" is something
radically different from what we do in Emacs Lisp.

> > As Alan I think rightly points out, this makes the language and all
> > tools that process the language more complex.  This is a high cost, so
> > the feature should deliver some real value.

> Certainly true. As the ordinary Lisp string syntax already allows
> multi-line strings, and interpolation is handled by the format function,
> the primary benefit is to turn off escaping. We could also offer a
> choice of opening and closing delimiters, though the proposed code
> didn't implement that.

> I think the benefit will be worth it. If we offered a little more choice
> of delimiters, then we could gain more benefit when the string must also
> contain double quotes. This need have a large complexity cost.

I think you meant to have a "not" in that last sentence, but also think
it is correct as it stands.

One of the things I didn't say explicitly in my last post was that with
any form of raw string, lisp would need to put a syntax-table text
property on each \ in such a string.  This needs to be done in an
after-change function, possibly assisted by a before-change function.
Any device to allow double quotes inside a raw string involves putting
syntax-table properties on these, too.

Having a choice of string delimiters makes things more complicated, too.

And all the while, some functionality needs to guard against such a "
becoming, or ceasing to be a raw string delimiter.

I can think of two ways to do these things: One is to clear the entire
raw string of all its syntax-table text properties at each change within
(or near) it, then reapply them all.  This could be slow in a big raw
string at normal typing speed.  The other way is to analyse carefully the
text in the vicinity of a change and alter the text properties minimally,
as needed.  C++ Mode takes this latter approach; it is complicated and
difficult to get right.

Currently, Emacs Lisp Mode doesn't need such change hooks.  Introducing
them would be a significant increase in complexity, and I think this
isn't worth it just to avoid having to quote backslashes in strings.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).