>>>>> Taras Zakharko
>>>>> on Tue, 7 Dec 2021 12:56:30 +0100 writes:
> I fully agree! General string interpolation opens a gaping security hole
and is accompanied by all kinds of problems and decisions. What I envision
instead is something like this:
> f”hello {name}”
> Which gets parsed by R to this:
> (STRINTERPSXP (CHARSXP (PROMISE nil)))
> Basically, a new type of R language construct that still can be processed
by packages (for customized interpolation like in cli etc.), with a default
eval which is basically paste0(). The benefit here would be that this is
eagerly parsed and syntactically checked, and that the promise code could carry
a srcref. And of course, that you could pass an interpolated string expression
lazily between frames without losing the environment etc… For more advanced
applications, a low level string interpolation expression constructor could be
provided (that could either parse a general string — at the user’s risk, or
build it directly from expressions).
> — Taras
Well, many months ago, R's NEWS (for R-devel, then became R 4.0.0)
contained
* There is a new syntax for specifying _raw_ character constants
similar to the one used in C++: r"(...)" with ... any character
sequence not containing the sequence )". This makes it easier to
write strings that contain backslashes or both single and double
quotes. For more details see ?Quotes.
This should be pretty close to what you propose above
(well, you need to replace your UTF-8 forward double quotes by
ASCII ones),
no ?
>> On 7 Dec 2021, at 12:06, Simon Urbanek <[email protected]>
wrote:
>>
>>
>>
>>> On Dec 7, 2021, at 22:09, Taras Zakharko <[email protected]
<mailto:[email protected]>> wrote:
>>>
>>> Great summary, Avi.
>>>
>>> String concatenation cold be trivially added to R, but it probably
should not be. You will notice that modern languages tend not to use “+” to do
string concatenation (they either have
>>> a custom operator or a special kind of pattern to do it) due to
practical issues such an approach brings (implicit type casting, lack of
commutativity, performance etc.). These issues will be felt even more so in R
with it’s weak typing, idiosyncratic casting behavior and NAs.
>>>
>>> As other’s have pointed out, any kind of behavior one wants from string
concatenation can be implemented by custom operators as needed. This is not
something that needs to be in the base R. I would rather like the efforts to be
directed on improving string formatting (such as glue-style built-in string
interpolation).
>>>
>>
>> This is getting OT, but there is a very good reason why string
interpolation is not in core R. As I recall it has been considered some time
ago, but it is very dangerous as it implies evaluation on constants which opens
a huge security hole and has questionable semantics (where you evaluate etc).
Hence it's much easier to ban a package than to hack it out of R ;).
>>
>> Cheers,
>> Simon
>>
>>> — Taras
[............]
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
