[Rd] g"string"

Henrik Bengtsson
Mon, 15 Dec 2025 18:25:02 -0000

> Would be nice sugar for end users to have...

A major problem with string interpolation is that it cannot be
validated until run-time unless it's standardized by the language
itself. For instance, if we have

name <- "world"
msg <- g("hello ${nane}")

we will not know about that typo until g() is called. Not being able
to catch coding errors until at run-time increases the amount of
luring bugs(*). The 'codetools' code inspection by 'R CMD check'
cannot "reach" into these "dynamic" strings, meaning we risk
shipping
broken code. It also prevents static-code inspection at run time, e.g.
identification of variables needed in order to resolve an expression
(useful for parallel processing etc.), much like y <- get(name) hides
things.

In order to safely introduce string interpolation, I think the best
would be to introduce a standard syntax that would allow for static
code inspection, e.g. g"hello ${nane}". That would make it possible to
validate the string interpolation during parsing, or immediately
after, but before evaluation.

If this could be handled by the parser, even better, e.g. have

name <- world"
msg <- g"hello ${nane}"

be parsed as:

name <- world"
msg <- paste0("hello ", as.character(nane))

This would have zero overhead at run-time, and would be fully
transparent to code inspection and validation tools. That would be
pure syntactic sugar, just like how the base-R pipe LHS |> RHS() is
identical to RHS(LHS).

(*) If we would do a bug analysis, I'm sure we would find more bugs
where string interpolation is used than where we compose such strings
using traditional paste() methods. I think this would be especially
true for rarely called code lines, e.g. calls to stop(). Anecdotally,
when R introduced built-in validation of the number and types of
sprintf() arguments, it revealed sprintf() bugs in several CRAN and
Bioconductor packages.

/Henrik

On Mon, Dec 15, 2025 at 8:16?AM Serguei Sokol via R-devel
<r-devel at r-project.org> wrote:
>
> Le 15/12/2025 ? 16:02, Gabor Grothendieck a ?crit :
> > I believe that would require a change to R itself.  If you can make do
> > with a workaround then
> >
> > 1. this works but has the drawback that you need to define your own
> > string class.  Below fmt
> > is an object with class "mystring".
> >
> >    as.mystring <- function(x) structure(x, class =
"mystring")
> >    "!.mystring" <- glue
> >
> >    fmt <- as.mystring("pi = {pi}")
> >    !fmt
> >    ## pi = 3.14159265358979
> Nice.
> Which makes me think why not to use "!" on a classical string?
Before
> now, it was a meaningless operation so no potential conflicts should
appear.
>
> # setting up
> `!` <- function(x) UseMethod("!") # make generic
> `!.default` <- base::`!` # preserve the old behavior for other classes
> `!.character`=glue::glue # make act as a glue on strings
>
> # usage
> !"pi={pi}"
> # pi=3.14159265358979
> !FALSE
> # [1] TRUE ## as before
>
> Best,
> Serguei.
>
> >
> > 2. Another workaround if you are going to subsequently pass that
> > resulting string to some other
> > function anyways is to preface that function with fn$.  It also
> > supports expressions surrounded
> > in backticks.  The function does not have to be cat.
> >
> >    library(gsubfn)
> >    fn$cat("pi = $pi\n")
> >    ## pi = 3.14159265358979
> >
> > On Sun, Dec 14, 2025 at 8:07?PM ivo welch <ivo.welch at
ucla.edu> wrote:
> >> One of the more convenient syntax sugars of perl is the embedding
of
> >> variables in strings, aka, `$s="I am $a";`. R has
similar functionality
> >> through library glue.  Alas, the library does not have the
operator
> >> flexibility to make it possible for glue to introduce a `g"I
am {a}"` .
> >>   (One can define g("I am {a}") but that steals more of
the function
> >> namespace.) Would be nice sugar for end users to have...
> >>
> >>          [[alternative HTML version deleted]]
> >>
> >> ______________________________________________
> >> R-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>
>
> --
> Serguei Sokol
> Ingenieur de recherche INRAE
>
> Cellule Math?matiques
> TBI, INSA/INRAE UMR 792, INSA/CNRS UMR 5504
> 135 Avenue de Rangueil
> 31077 Toulouse Cedex 04
>
> tel: +33 5 61 55 98 49
> email: sokol at insa-toulouse.fr
>
https://www.toulouse-biotechnology-institute.fr/en/plateformes-plateaux/cellule-mathematiques/
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel