From kev|nu@hey @end|ng |rom gm@||@com  Wed Dec  8 00:13:56 2021
From: kev|nu@hey @end|ng |rom gm@||@com (Kevin Ushey)
Date: Tue, 7 Dec 2021 15:13:56 -0800
Subject: [Rd] String interpolation [Was: string concatenation operator
 (revisited)]
In-Reply-To: <98866BE8-AA8B-45DC-85CB-D51AEE625533@R-project.org>
References: <mailman.52192.3.1638702001.27673.r-devel@r-project.org>
 <20211206061402.GA3810@mail.cs.toronto.edu>
 <b3509a16-a132-8a4e-322f-ccb708d12ff1@gmail.com>
 <20211206180302.GA6850@mail.cs.toronto.edu>
 <CAD4oTHGLQVLwaLCcZtY3YqTg8PP6Y0Ji5ZNueND=uwSSGtZ5DA@mail.gmail.com>
 <CAL6gwn+B+MP7-s2bgQq+GCAyF2vVdS3KtBR4Zot-pVYzGLQW9g@mail.gmail.com>
 <82ea4836-96dd-b979-e684-018354cb3f33@gmail.com>
 <CAHqSRuRxwGRf9to5uNMXXZiJuB6oa_uF_3UKY_2y80t=CnRiYw@mail.gmail.com>
 <CAD4oTHE=Ap+NnQQeOWbexnQcvHYJ14rQdt9c7NZdp1D1BiEuOQ@mail.gmail.com>
 <010101d7eb09$8c0156d0$a4040470$@verizon.net>
 <7CA551D8-3636-4E03-AF4C-0BDD4F5FB9F4@uzh.ch>
 <921415D6-E68C-41EE-A836-25B30668A00C@R-project.org>
 <F8A25DDA-EB48-46EB-8D4E-04783E7F5731@uzh.ch>
 <98866BE8-AA8B-45DC-85CB-D51AEE625533@R-project.org>
Message-ID: <CAJXgQP1ir2gurPusQDJXfmvJZYBtnKztKkUU5shvTBMq1Nj2ow@mail.gmail.com>

For what it's worth, you can also get 90% of the way there with:

    f <- glue::glue
    f("if you squint, this is a Python f-string")

Having this in an add-on package also makes it much easier to change
in response to user feedback; R packages have more freedom to make
backwards-incompatible changes.

That said, if something like this were to happen in R, my vote would
be an implementation in the parser that transformed f"string" into
something like 'interpolate("string")', so that f"string" would just
become syntactic sugar for already-existing code (and so such code
could remain debuggable, easy to reason about, etc without any changes
to R internals)

Thanks,
Kevin

On Tue, Dec 7, 2021 at 2:06 PM Simon Urbanek
<simon.urbanek at r-project.org> wrote:
>
> I don't think a custom type alone would work, because users would expect to use such string anywhere a regular string can be used, and that's where the problems start - the evaluation would have to happen at a point where it is not expected since we can assume today that CHAR() doesn't evaluate. If it's just construct that needs some function call to turn it into a real string, then that's (from user's perspective) no different than glue() so I don't think the users would see the benefit (admittedly, you could do a lot more with such internal type, but not sure if the complexity is worth it).
>
> Cheers,
> Simon
>
>
>
> > On Dec 8, 2021, at 12:56 AM, Taras Zakharko <taras.zakharko at uzh.ch> wrote:
> >
> > I fully agree! General string interpolation opens a gaping security hole and is accompanied by all kinds of problems and decisions. What I envision instead is something like this:
> >
> >   f?hello {name}?
> >
> > Which gets parsed by R to this:
> >
> >   (STRINTERPSXP (CHARSXP (PROMISE nil)))
> >
> > Basically, a new type of R language construct that still can be processed by packages (for customized interpolation like in cli etc.), with a default eval which is basically paste0(). The benefit here would be that this is eagerly parsed and syntactically checked, and that the promise code could carry a srcref. And of course, that you could pass an interpolated string expression lazily between frames without losing the environment etc? For more advanced applications, a low level string interpolation expression constructor could be provided (that could either parse a general string ? at the user?s risk, or build it directly from expressions).
> >
> > ? Taras
> >
> >



[Rd] String interpolation [Was: string concatenation operator (revisited)]
Kevin Ushey