Have we talked this topic out yet?
As has been mentioned, R allows many strategies with perhaps the simplest being
to use the paste functions. Here, is a not simpler version where you do a
global substitution that removes it alongside the artificial newlines.
gsub(pattern="\n",
replacement="",
x="Hello
And
Goodbye")
Result:
[1] "HelloAndGoodbye"
Is it worth the bother? I think not . It does work but I suspect gsub (or
similar functions) that do a lot more, may be as inefficient or even more than
the paste0 alternative.
-----Original Message-----
From: R-devel <r-devel-boun...@r-project.org> On Behalf Of Simon Urbanek
Sent: Monday, June 2, 2025 7:48 PM
To: Henrik Bengtsson <henrik.bengts...@gmail.com>
Cc: r-devel@r-project.org
Subject: Re: [Rd] Specifying a long string literal across several lines
> 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
