Email list hosting service & mailing list manager

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