FWIW {stringi} has %+% for this functionality (and I occasionally use
it), tho I do enough processing of quite ughly string content that I
pretty much always have {stringi} loaded. That may not be true for
many other folks.
On Fri, Dec 10, 2021 at 2:07 PM Grant McDermott wrote:
>
> Sorry I
Sorry I haven't had a chance to reply to anyone. I feel like I dropped a
grenade in a room and promptly bolted...
Just to say, then, that I really appreciate everyone's comments and
suggestions. While I'm tempted to push back on some points, I don't think it's
worth on balance, or will add
bugs after
getting complaints about code that does not work the same anymore!
-Original Message-
From: R-devel On Behalf Of Taras Zakharko
Sent: Tuesday, December 7, 2021 4:09 AM
To: r-devel
Subject: Re: [Rd] string concatenation operator (revisited)
Great summary, Avi.
Stri
at realistically they can
only approve a small number for each release and often then have to spend more
time fixing bugs after getting complaints about code that does not work the
same anymore!
-Original Message-
From: R-devel On Behalf Of Taras Zakharko
Sent: Tuesday, December 7, 202
> 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
> 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
__
+"3" becoming "23" rather
>>> than 5. Right now, I can use as.numeric("2")+as.numeric("3") and get the
>>> intended result after making very clear to anyone reading the code that I
>>> wanted strings converted to floating point befor
ear to anyone reading the code that I
>> wanted strings converted to floating point before the addition.
>>
>> As has been pointed out, the plus operator if used to concatenate does not
>> have a cognate for other operations like -*/ and R has used most other
>> speci
g said that, the makers of Python did make that
choice.
-Original Message-
From: R-devel On Behalf Of Gabriel Becker
Sent: Monday, December 6, 2021 7:21 PM
To: Bill Dunlap
Cc: Radford Neal ; r-devel
Subject: Re: [Rd] string concatenation operator (revisited)
As I recall, there
re
> is a tad confusing. Having said that, the makers of Python did make that
> choice.
>
> -Original Message-
> From: R-devel On Behalf Of Gabriel Becker
> Sent: Monday, December 6, 2021 7:21 PM
> To: Bill Dunlap
> Cc: Radford Neal ; r-devel
> Subject: Re: [Rd]
it is not already being used for something but using + here
is a tad confusing. Having said that, the makers of Python did make that
choice.
-Original Message-
From: R-devel On Behalf Of Gabriel Becker
Sent: Monday, December 6, 2021 7:21 PM
To: Bill Dunlap
Cc: Radford Neal ; r-devel
>I think a lot of these things ultimately mean that if there were to be a
string >concatenation operator, it probably shouldn't have behavior
identical to >paste0. Was that what you were getting at as well, Bill?
Yes.
On Mon, Dec 6, 2021 at 4:21 PM Gabriel Becker wrote:
> As I recall, there
I am surprised nobody so far has mentioned glue which is an
implementation in R of a python idiom.
It is a reverse import in a great number of R packages on CRAN. It
specifies how some of the special cases so far considered are treated
which seems an advantage:
> library(glue)
> glue(NA, 2)
As I recall, there was a large discussion related to that which resulted in
the recycle0 argument being added (but defaulting to FALSE) for
paste/paste0.
I think a lot of these things ultimately mean that if there were to be a
string concatenation operator, it probably shouldn't have behavior
Should paste0(character(0), c("a","b")) give character(0)?
There is a fair bit of code that assumes that paste("X",NULL) gives "X" but
c(1,2)+NULL gives numeric(0).
-Bill
On Mon, Dec 6, 2021 at 1:32 PM Duncan Murdoch
wrote:
> On 06/12/2021 4:21 p.m., Avraham Adler wrote:
> > Gabe, I agree that
On 06/12/2021 4:21 p.m., Avraham Adler wrote:
Gabe, I agree that missingness is important to factor in. To somewhat abuse
the terminology, NA is often used to represent missingness. Perhaps
concatenating character something with character something missing should
result in the original
Gabe, I agree that missingness is important to factor in. To somewhat abuse
the terminology, NA is often used to represent missingness. Perhaps
concatenating character something with character something missing should
result in the original character?
Avi
On Mon, Dec 6, 2021 at 3:35 PM Gabriel
Hi All,
Seeing this and the other thread (and admittedly not having clicked through
to the linked r-help thread), I wonder about NAs.
Should NA "hi there" not result in NA_character_? This is not
what any of the paste functions do, but in my opinoin, NA +
seems like it should be NA (not
> > In pqR (see pqR-project.org), I have implemented ! and !! as binary
> > string concatenation operators, equivalent to paste0 and paste,
> > respectively.
> >
> > For instance,
> >
> > > "hello" ! "world"
> > [1] "helloworld"
> > > "hello" !! "world"
> > [1] "hello world"
On 06/12/2021 1:14 a.m., Radford Neal wrote:
The TL;DR version is base R support for a `+.character` method. This
would essentially provide a shortcut to `paste0`...
In pqR (see pqR-project.org), I have implemented ! and !! as binary
string concatenation operators, equivalent to paste0 and
> The TL;DR version is base R support for a `+.character` method. This
> would essentially provide a shortcut to `paste0`...
In pqR (see pqR-project.org), I have implemented ! and !! as binary
string concatenation operators, equivalent to paste0 and paste,
respectively.
For instance,
>
On 05/12/2021 7:22 a.m., Ivan Krylov wrote:
On Sat, 4 Dec 2021 21:26:05 -0500
Avi Gross via R-devel wrote:
In many languages, like PERL, this results in implicated conversion
to make "text1" the result.
FWIW, Perl5 has a separate string concatenation operator (".") in order
to avoid
Ivan Krylov wrote:
> FWIW, Perl5 has a separate string concatenation operator (".") in order
> to avoid potential confusion with addition. So do Lua (".."), SQL
> ("||", only some of the dialects) and Raku ("~", former Perl6).
Indeed, using the same operator '+' for addition and string
On Sat, 4 Dec 2021 21:26:05 -0500
Avi Gross via R-devel wrote:
> In many languages, like PERL, this results in implicated conversion
> to make "text1" the result.
FWIW, Perl5 has a separate string concatenation operator (".") in order
to avoid potential confusion with addition. So do Lua
Hello,
Bert Gunter started a very recent R-Help thread [1] about the following
method not working.
`+.character` <- function(x, y) paste0(x, y)
The discussion is worth reading and at least partly answers to the
reason why the feature request has never made it to base R.
It goes without
Grant,
One nit to consider is that the default behavior of pasteo() to include a space
as a separator would not be a perfect choice for the usual meaning of plus.
I would prefer a+b to be "helloworld" in your example and to get what you say
would be
a + " " + b
Which I assume would put in
27 matches
Mail list logo
