I also suspect the byte compiler could constant-fold some of these
common paste expressions, effectively negating any potential runtime
cost of `paste` / `paste0` with string literals.
Beyond the syntax restrictions for automatic concatenation of
sequential string literals, it's also a big footgun. It's easy to
accidentally write code like this:
yum <- c(
"apple",
"banana",
"cherry"
"danish"
)
and in this scenario, instead of an error, you'd just quietly get 3
strings instead of the intended 4. This sort of code is easy to
accidentally write if you're updating an existing list by adding
another member.
All this said, I think the conversation has strayed from the original
request, which was around whether R could handle EOL escapes as a
means of creating longer strings. I think it's a reasonable request,
but it does lead to (IMHO) awkward code where you might have an
indented code block, but a multiline string which would no longer
match the code indentation. That's ultimately a matter of taste,
though.
For what it's worth, I've occasionally defined helper functions which
try to trim common indentation and join newlines in long strings, e.g.
z <- function(text, collapse = " ") {
trimmed <- gsub("^\\s*\\n|\\n\\s*$", "", text)
lines <- strsplit(trimmed, "\n", fixed = TRUE)[[1L]]
indent <- regexpr("[^[:space:]]", lines)
common <- min(setdiff(indent, -1L))
paste(substring(lines, common, nchar(lines)), collapse = collapse)
}
with example:
> z('
+ This is some text.
+ It spans multiple lines.
+ ')
[1] "This is some text. It spans multiple lines."
and personally I prefer reading (and writing) longer strings in this
form, as opposed to adorning text with trailing slashes.
Best,
Kevin
On Mon, Jun 2, 2025 at 4:49 PM Simon Urbanek
<simon.urba...@r-project.org> wrote:
>
>
>
> > On 3 Jun 2025, at 09:34, Henrik Bengtsson <henrik.bengts...@gmail.com>
> > wrote:
> >
> > One could also argue that paste0("a", "b", "c") is a function call that
> > needs to be evaluated at runtime, whereas "abc" is a string constant
> > understood by the parser, and often also language agnostic. I'd assume
> > compilers and code- and text-search tools do a better job with the latter.
> >
>
>
> Well, about that, just to illustrate how insane that is:
>
> $ cat foo.py
> if True:
> a = "foo\
> bar\
> !"
> print(a)
> $ python3 foo.py
> foo bar !
>
> in particular for a language that insist on the space being part of the
> syntax ;) - so it forces you to indent things and yet it breaks badly in
> those strings.
>
> I don’t have a strong opinion, but I agree that it is very bad for
> readability so definitely not something that should be recommended.
>
> That said, in R we tend to offer many tools that allow you to shoot yourself
> in the foot, so some might argue that one more is not going to hurt ;) - not
> everyone wants their code to be readable…
>
> Cheers,
> Simon
>
>
> >
> >
> > On Mon, Jun 2, 2025 at 2:18 PM Josiah Parry <josiah.pa...@gmail.com> wrote:
> >>
> >> 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
> >
>
> ______________________________________________
> 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
