My two cents (soon to be discontinued) is that it is not very relevant to compare one computer language ALREADY DESIGNED to another and insist they become the same. Next we will be asked to allow "+" or just adjacency to connect two or more quoted strings because, well, Python does that. Then, we can ask Python to give up using indentation and start using braces because R does that.
Paste and paste0 were planned as THE way R implements what is wanted. Sure, you could create functions with names like %plus% or %concat% or even overload that allow you to implement paste inline but is that much of a gain? Note suggestions here of things that could easily break if certain changes are blindly made. Here is a trivial solution using %>>>% as an in-line operator you can replace with anything you want: [1] "HelloThereCruelworld" > `%>>>%`<- function(a,b) paste0(a,b) > "Hello" %>>>% "There" %>>>% "Cruel" %>>>% "World" [1] "HelloThereCruelWorld" But you want a multi-line approach this works the same: "Hello" %>>>% "There" %>>>% "Cruel" %>>>% "World" No backslashes, just the function name at the end of each line. I question how it would be faster than paste or even more readble as the above called paste0 multiple times plus calls a function multiple times. What exactly is wrong with this: paste0( "Hello", "There", "Cruel", "World" ) If properly written, you can even place the text left-justified or wherever and it should be quite readable. Having said that, yes, it can be very nice to use languages designed differently. R can be used in ways you might not imagine given delayed evaluations. The price of a paste0 call is compensated for by the simplification of some other things but note other packages handling strings are available now like stringi and stringr that may give you some other things you want. You can even overload something like + this way but do NOT do that as it messes lots of things up: `+`<- function(a,b) paste0(a,b) "first" + "Second" + "Third" A safer approach like the above could be creating your own "objects" that hold text and arranging for that object to treat plus )or other symbols) specially. I would say on the list of changes and updates to R, this feature may not look like it is worthwhile and may break things. If this feature is really that important to you, and you use it many times in your program, there are fairly oddball solutions such as running a program in an environment (as in POSIT RSTUDIO) that allows python and R to work together on a single set of data so python can be used to create variables like the ones you want and R can then use them. I suspect you might find such a solution far worse than just using R the way it was designed. -----Original Message----- From: R-devel <r-devel-boun...@r-project.org> On Behalf Of Josiah Parry Sent: Monday, June 2, 2025 5:18 PM To: Kasper Daniel Hansen <kasperdanielhan...@gmail.com> Cc: r-devel@r-project.org Subject: Re: [Rd] Specifying a long string literal across several lines I suppose taste is learned as well. It does feel quite odd that the best way to define a long string without a note or text wrapping is by being creative with functions. This is valid in Python, Julia, and Rust (if you add `let` and a terminating semi-colon): my_str = "part1\ part2\ part2" I don't think it is abnormal to expect or desire this type of functionality in our favorite language. On Mon, Jun 2, 2025 at 13:59 Kasper Daniel Hansen < kasperdanielhan...@gmail.com> wrote: > Like Tomas, I find the paste0 readability to be **much** better, partly > because it allows for better indentation (as Tomas pointed out). Perhaps a > pointless email, but sometimes - for these subjective issues - it is > worthwhile to point out a difference in opinion. > > Best, > Kasper > > On Mon, Jun 2, 2025 at 12:27 PM Tomas Kalibera <tomas.kalib...@gmail.com> > wrote: > >> >> On 6/2/25 17:37, Josiah Parry wrote: >> > Tomas, >> > >> > Here is a good example of where this functionality would be useful: >> > >> https://github.com/R-ArcGIS/arcgislayers/blob/2b29f4c254e7e5a1dadce8d4b0015a70dfae39d4/R/arc-open.R#L19-L56 >> > >> > In order to prevent R CMD check notes I have to use `paste0()` to >> > concatenate long URLs. If we were able to use `\` to >> > separate the string across multiple lines, it would make the solution >> > much nicer! >> >> It may be a matter of taste. To me the current form >> >> #' furl <- paste0( >> #' "https://services3.arcgis.com/ZvidGQkLaDJxRSJ2/arcgis/rest/services/";, >> #' "PLACES_LocalData_for_BetterHealth/FeatureServer/0" >> #' ) >> #' >> >> would be actually clearer than say this: >> >> #' # FeatureLayer >> #' furl <- >> "https://services3.arcgis.com/ZvidGQkLaDJxRSJ2/arcgis/rest/services/\ >> PLACES_LocalData_for_BetterHealth/FeatureServer/0 >> <https://services3.arcgis.com/ZvidGQkLaDJxRSJ2/arcgis/rest/services/%5CPLACES_LocalData_for_BetterHealth/FeatureServer/0> >> " >> #' >> >> Inside a per-line comment (#), a backslash followed by a newline would >> probably be disallowed, anyway - e.g. in C it is considered dangerous >> and is discouraged. And the code resulting from splices is hard to read >> due to missing indentation. There is also risk of accidentally putting a >> space after the backslash before the end of line (which some >> languages/parsers then don't treat as a splice, some do, some issue a >> warning - of course it is hard to see in the code). >> >> The idea of automatically concatenating consecutive string literals as >> in C would not easily work in R. This is now valid R code: >> >> x <- "part1" >> "part2" >> >> if we introduced concatenation, we would change behavior of this code >> (the value of x would be different, the result of these two lines would >> be different). >> >> I think paste0() is not that bad in the end. >> >> Best >> Tomas >> >> > On Mon, Jun 2, 2025 at 3:19 AM Tomas Kalibera >> > <tomas.kalib...@gmail.com> wrote: >> > >> > >> > On 5/28/25 04:15, Pavel Krivitsky via R-devel wrote: >> > > Dear All, >> > > >> > > Perhaps this should go in r-package-devel, but I suspect that >> > this is >> > > going to turn into a feature request, and I want to run it by >> > the list >> > > before filing it in the Bugzilla. >> > > >> > > I would like to specify a long string literal without making the >> > line >> > > of code too long. In R, >> > > >> > > "abc >> > > def" >> > > >> > > yields the string "abc\def", and, as far as I can tell, there is >> no >> > > mechanism for preventing it from inserting a newline into the >> > string. >> > > >> > > Putting a backslash before the newline, i.e., >> > > >> > > "abc\ >> > > def" >> > > >> > > eliminates the newline in (that I know of) C/C++, Python, and >> Julia, >> > > but it makes no difference in R. >> > > >> > > The implicit concatenation of Python and C/C++, e.g., "abc" >> > "def", is a >> > > syntax error as well in R. >> > > >> > > It is, of course, possible to use paste0(), but is there a more >> > concise >> > > built-in mechanism in R of which I am not aware? >> > > >> > > If not, I think it would make sense to bring R in line with the >> > others. >> > > Currently, backslash and no backslash before a newline behave >> > > identically (at least as far as I can tell), so I doubt that a >> > > nontrivial amount of code relies on the current behaviour. [1] >> > >> > What would be real example of a long string literal you would want >> to >> > enter this way? >> > >> > For entering a long text with newlines, one can use raw strings in R >> > (see ?Quotes) - but there you would see the newlines and >> indentation. >> > I've seen code where "paste0" has been aliased to a local function >> > named with a single letter to make concatenation more concise. >> > >> > Best >> > Tomas >> > >> > > >> > > Any thoughts? >> > > Pavel >> > > >> > > [1] On the off chance that it does, it should easy to check by >> > > searching for "\\\n" in package sources, because a backslash >> > before a >> > > newline is a syntax error outside a string. >> > > ______________________________________________ >> > > R-devel@r-project.org mailing list >> > > https://stat.ethz.ch/mailman/listinfo/r-devel >> > >> > ______________________________________________ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> > >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > -- > Best, > Kasper > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
