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
On 07/12/2021 4:09 a.m., Taras Zakharko 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 pat
> On Dec 7, 2021, at 22:09, Taras Zakharko 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
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 ty
Dear list,
There is a minor typo in addmargins (section Details):
- If the functions used to form margins are not commutative the result depends
on the order in which margins are computed. Annotation of margins is done via
naming the FUN list.
+ If the functions used to form margins are not com
Thomas SOEIRO wrote:
> Dear list,
> There is a minor typo in addmargins (section Details):
> - If the functions used to form margins are not commutative the result
> depends on the order in which margins are computed. Annotation of margins is
> done via naming the FUN list.
> + If the function
Yes, it is!
There is only a small typo (missing punctuation for easier reading)
Sorry for the misunderstanding, it may not be clear enough in my previous mail.
-Message d'origine-
De : GILLIBERT, Andre [mailto:andre.gillib...@chu-rouen.fr]
Envoyé : mardi 7 décembre 2021 16:59
À : SOEIRO
On 8 December 2021 at 00:06, Simon Urbanek wrote:
| Hence it's much easier to ban a package than to hack it out of R ;).
Paging Achim for suggested `fortunes` inclusion.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-d
> 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
> Martin Maechler
> on Tue, 7 Dec 2021 18:35:00 +0100 writes:
> 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 e
I don't think a custom type alone would work, because users would expect to use
such string anywhere a regular string can be used, and that's where the
problems start - the evaluation would have to happen at a point where it is not
expected since we can assume today that CHAR() doesn't evaluate.
For what it's worth, you can also get 90% of the way there with:
f <- glue::glue
f("if you squint, this is a Python f-string")
Having this in an add-on package also makes it much easier to change
in response to user feedback; R packages have more freedom to make
backwards-incompatible cha
Taras and Duncan and others do make a point about things not needing to be
built in to the base R distribution if something similar can already be found
elsewhere.
To an extent, that is quite true. But what exactly should be in the core of a
language that has this kind of extensibility?
I not
> I don't think a custom type alone would work, because users would expect to
> use such string anywhere a regular string can be used, and that's where the
> problems start - the evaluation would have to happen at a point where it is
> not expected since we can assume today that CHAR() doesn't e
14 matches
Mail list logo
