similar to: [WISH / PATCH] possibility to split string literals across multiple lines

I don't think it is reasonable to change the parser this way. This is currently valid R code: a <- "foo" "bar" and with the new syntax, it is also valid, but with a different meaning. Or you can even consider a <- "foo" bar %>% func() %>% print() etc. I like the idea of string literals, but the C/C++ way clearly does not work. The Python/Julia way

On 16/06/2017 2:04 PM, Radford Neal wrote: >> On Wed, 14 Jun 2017, G?bor Cs?rdi wrote: >> >>> I like the idea of string literals, but the C/C++ way clearly does not >>> work. The Python/Julia way might, i.e.: >>> >>> """this is a >>> multi-line >>> lineral""" >> >> luke-tierney at uiowa.edu:

On Fri, Jun 16, 2017 at 7:04 PM, Radford Neal <radford at cs.toronto.edu> wrote: >> On Wed, 14 Jun 2017, G?bor Cs?rdi wrote: >> >> > I like the idea of string literals, but the C/C++ way clearly does not >> > work. The Python/Julia way might, i.e.: >> > >> > """this is a >> > multi-line >> >

Hi, I would really like to have a way to split long string literals across multiple lines in R. Currently, if a string literal spans multiple lines, there is no way to inhibit the introduction of newline characters: > "aaa + bbb" [1] "aaa\nbbb" If a line ends with a backslash, it is just ignored: > "aaa\ + bbb" [1] "aaa\nbbb" We could use

On Wed, Jun 14, 2017 at 8:48 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote: > As I recall this has been discussed at least a few times (unfortunately I'm traveling so can't check the references), but the justification was never satisfactory. > > Personally, I wouldn't mind string continuation supported since it makes for more readable code (I had one of my

Mark, that's actually a fair statement, although your extra operator doesn't cause construction at parse time. You still call paste0(), but just add an extra layer on top of it. I also doubt that even in gigantic loops the benefit is going to be significant. Take following example: atestfun <- function(x){ y <- paste0("a very long", "string for

On Wed, 14 Jun 2017 06:12:09 -0500, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 14/06/2017 5:58 AM, Andreas Kersting wrote: > > Hi, > > > > I would really like to have a way to split long string literals across > > multiple lines in R. > > I don't understand why you require the string to be a literal. Why not > construct the long

On Wed, 14 Jun 2017, G?bor Cs?rdi wrote: > I don't think it is reasonable to change the parser this way. This is > currently valid R code: > > a <- "foo" > "bar" > > and with the new syntax, it is also valid, but with a different > meaning. Or you can even consider > > a <- "foo" > bar %>% func() %>% print() > >

Having some line-breaking character for string literals would have benefits as string literals can then be constructed parse-time rather than run-time. I have run into this myself a few times as well. One way to at least emulate something like that is the following. `%+%` <- function(x,y) paste0(x,y) "hello" %+% " pretty" %+% " world" -Mark Op wo 14 jun.

I know it doesn't cause construction at parse time, and it was also not what I said. What I meant was that it makes the syntax at least look a little as if you have a line-breaking character within string literals. Op wo 14 jun. 2017 om 14:18 schreef Joris Meys <jorismeys at gmail.com>: > Mark, that's actually a fair statement, although your extra operator > doesn't cause

Gabor Csardi writes: > Btw. for some motivation, here is a (surely incomplete) list of > languages with '+' as the string concatenation operator: > > ALGOL 68, BASIC, C++, C#, Cobra, Pascal, Object Pascal, Eiffel, Go, > JavaScript, Java, Python, Turing, Ruby, Windows Powers hell, > Objective-C, F#, Sc-ala, Ya. The situation for R is rather different from that of a

On 14/06/2017 6:45 AM, Andreas Kersting wrote: > On Wed, 14 Jun 2017 06:12:09 -0500, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > >> On 14/06/2017 5:58 AM, Andreas Kersting wrote: >>> Hi, >>> >>> I would really like to have a way to split long string literals across >>> multiple lines in R. >> >> I don't understand why

On 14/06/2017 5:58 AM, Andreas Kersting wrote: > Hi, > > I would really like to have a way to split long string literals across > multiple lines in R. I don't understand why you require the string to be a literal. Why not construct the long string in an expression like paste0("aaa", "bbb") ? Surely the execution time of the paste0 call is

As I recall this has been discussed at least a few times (unfortunately I'm traveling so can't check the references), but the justification was never satisfactory. Personally, I wouldn't mind string continuation supported since it makes for more readable code (I had one of my packages raise a NOTE in examples because there is no way in R to split a long hash into multiple lines), but

If you are changing the parser (which is a major change) you might consider treating strings in the C/C++ way: char *s = "A" "B"; means the same as char *s = "AB"; I am not a big fan of that syntax but it is widely used. A backslash at the end of the line leads to errors when you accidently put a space after the backslash and the editor

The current R release candidate has a lack of protect bug (of very long standing) with respect to the R_print.na_string and R_print.na_string_noquote fields of the static R_print structure declared in Print.h. This shows up very occassionally as incorrect output from the following lines in reg-tests-2.R: x <- c("a", NA, "b") factor(x) factor(x, exclude="")

In testing pqR on Solaris SPARC systems, I have found two bugs that are also present in recent R Core versions. You can see the bugs and fixes at the following URLs: https://github.com/radfordneal/pqR/commit/739a4960a4d8f3a3b20cfc311518369576689f37 https://github.com/radfordneal/pqR/commit/339b7286c7b43dcc6b00e51515772f1d7dce7858 The first bug, in nls, is most likely to occur on a 64-bit

> I propose a patch to ifelse that leverages anyNA(test) to achieve an > improvement in performance. For a test vector of length 10, the change > nearly halves the time taken and for a test of length 1 million, there > is a tenfold increase in speed. Even for small vectors, the > distributions of timings between the old and the proposed ifelse do > not intersect. For smaller

I've been getting pqR to work on windows systems, and in the process have discovered various problems with R core versions of R and with Rtools. One is with the implementation of OpenMP in 64-bit Rtools. This problem is in Rtools215 and Rtools33, and presumably all the ones in between. You can see the problem with the following test program: #include <stdio.h> #include <omp.h>

Gabriel Becker writes: AFAIK R does not automatically copy function arguments. R actually tries very hard to avoid copying while maintaining "pass by value" functionality. ... R only copies data when you modify an object, not when you simply pass it to a function. This is a bit misleading. R tries to avoid copying by maintaining a count of how many references there are to an