> 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
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
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
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.
> 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
> 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
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
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
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
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
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
> 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
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
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
14 matches
Mail list logo
