raw string literals lloda (16 Jun 2022 19:52 UTC)
|
Re: raw string literals
Per Bothner
(16 Jun 2022 20:08 UTC)
|
Re: raw string literals
Lassi Kortela
(16 Jun 2022 21:49 UTC)
|
Re: raw string literals
lloda
(17 Jun 2022 17:44 UTC)
|
Re: raw string literals
Arthur A. Gleckler
(17 Jun 2022 17:52 UTC)
|
Re: raw string literals
Lassi Kortela
(17 Jun 2022 19:59 UTC)
|
Re: raw string literals
lloda
(17 Jun 2022 17:34 UTC)
|
raw string literals lloda 16 Jun 2022 19:52 UTC
Hello, I have prepared a draft SRFI for raw string literals. The draft is here: https://github.com/lloda/guile-raw-strings/blob/master/srfi.md, but I describe the general ideal below. Raw string literals do not support escapes, instead every character is used for its own value. These are useful for strings that contain \ by themselves, such as regexps, or when quoting code verbatim. There are several ways one could design this syntax. I've picked one that makes sense to me, but I'd like to read some opinions before I consider submitting the draft. The proposal is of the form #Rdelimiter"string"delimiter This is based on C++ raw string literals, which are of the form R"delimiter(string)delimiter" On C++ the R is a prefix for ", so the delimiter must come after ". In my proposal, #R is a unique prefix which makes the () unnecessary. On the other hand using #R"delimiter()delimiter" would allow #Rx where x is not " to be used for future purposes. Perhaps having the construction always end with " is helpful in some way. One could argue that the custom delimiters aren't necessary. For example Python gets away with just r"string". On the other hand Python also has '' and """ etc. An option to avoid custom delimiters is to allow other characters to be used for the role of "". For example allowing () #R(str"ing) in addition to #R"str(]ing" and possibly other pairs. Still, custom delimiters solve the problem more generally. Regards Daniel