Front page | perl.perl5.porters |
Postings from June 2022
Re: pre-RFC: template strings
Thread Previous
|
Thread Next
From:
Walt Mankowski
Date:
June 12, 2022 21:01
Subject:
Re: pre-RFC: template strings
Message ID:
99f9254d-ecaa-460f-b356-332dbd3a4185@www.fastmail.com
--301ba8ed5df14c30bdf260cfadda5ad5
Content-Type: text/plain
On Sun, Jun 12, 2022, at 3:10 PM, Oodler 577 wrote:
> * Ricardo Signes <perl.p5p@rjbs.manxome.org> [2022-06-12 14:46:38 -0400]:
>
> > Porters,
> >
> > I like the current proposal for a ?-> operator, but `qq{Foo $Bar?->[0]}` would become weird. Either it would optionally dereference or it would not match the normal expression when interpolating. (Methods not working this way already confuse people.) The same problem already exists for postfix dereferencing like `qq{$Foo->@*}` without the postderef_qq feature.
> >
> > I would like to propose we blithely steal template literals from JavaScript, with some modifications. We add a new quote-like operator, "qt", which does not interpolate like qq, but has its own method for interpolation. We ignore the "tagged templates" feature of JavaScript.
> >
> > In a qt string, there are two special forms: `${ EXPR }` and `@{ EXPR }`. These evaluate the expression in them in scalar and list contexts, respectively, and then interpolate the result. The list form joins the list elements with `$"`.
> >
> > This eliminates the need for the `@{[ ? ]}` form in qq strings. It means you can easily interpolate method calls and simple expressions like $a+$b.
> >
> > I'm not 100% happy with the propose spelling of the special forms, and we could get by eliminating the list one (because "join" exists). I think the feature's worth adding, anyway. Objections / endorsements before I write something more formal?
> >
>
> At first glance, I like this. Two things come to mind, the "templating" that we
> already have: format (which I still don't grok) and subroute prototypes. Rather
> than constructing a 3rd kind of templating approach, are there things that can
> be applied or avoided - or dare I say improved - in considering this?
I think your confusion might come from using the word "templating" to describe 3 things which are quite different. Formats are basically just a way to produce ASCII reports. Subroutine prototypes describe the parameters to a function.
This template string proposal, in contrast, is a more robust way to evaluate expressions inside strings.
Naming aside, it's hard for me to imagine that anyone could get these confused with each other.
> FWIW, I'd love to see an RFC on this kind of thing. In particular, I am interested
> in seeing what the forms start to look like and what idioms might be improved
> or created.
The proposal seems similar in spirit to f-strings in Python, a relatively new addition to the language which quickly became one of my favorite features. I'm also like to see how it will look in Perl!
Walt
--301ba8ed5df14c30bdf260cfadda5ad5
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sun, Jun 12,=
2022, at 3:10 PM, Oodler 577 wrote:<br></div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>* Ricardo Signes <<a href=3D"mailto:perl.p5=
p@rjbs.manxome.org">perl.p5p@rjbs.manxome.org</a>> [2022-06-12 14:46:=
38 -0400]:<br></div><div><br></div><div>> Porters,<br></div><div>>=
<br></div><div>> I like the current proposal for a ?-> opera=
tor, but `qq{Foo $Bar?->[0]}` would become weird. Either it wou=
ld optionally dereference or it would not match the normal expression wh=
en interpolating. (Methods not working this way already confuse pe=
ople.) The same problem already exists for postfix dereferencing l=
ike `qq{$Foo->@*}` without the postderef_qq feature.<br></div><div>&g=
t; <br></div><div>> I would like to propose we blithely steal te=
mplate literals from JavaScript, with some modifications. We add a=
new quote-like operator, "qt", which does not interpolate like qq, but =
has its own method for interpolation. We ignore the "tagged templa=
tes" feature of JavaScript.<br></div><div>> <br></div><div>> =
In a qt string, there are two special forms: `${ EXPR }` and `@{ E=
XPR }`. These evaluate the expression in them in scalar and list c=
ontexts, respectively, and then interpolate the result. The list f=
orm joins the list elements with `$"`.<br></div><div>> <br></div=
><div>> This eliminates the need for the `@{[ ? ]}` form in qq string=
s. It means you can easily interpolate method calls and simple exp=
ressions like $a+$b.<br></div><div>> <br></div><div>> I'm not=
100% happy with the propose spelling of the special forms, and we could=
get by eliminating the list one (because "join" exists). I think =
the feature's worth adding, anyway. Objections / endorsements befo=
re I write something more formal?<br></div><div>> <br></div><div=
><br></div><div>At first glance, I like this. Two things come to mind, t=
he "templating" that we<br></div><div>already have: format (which I stil=
l don't grok) and subroute prototypes. Rather<br></div><div>than constru=
cting a 3rd kind of templating approach, are there things that can<br></=
div><div>be applied or avoided - or dare I say improved - in considering=
this?<br></div></blockquote><div><br></div><div>I think your confusion =
might come from using the word "templating" to describe 3 things which a=
re quite different. Formats are basically just a way to produce ASCII re=
ports. Subroutine prototypes describe the parameters to a function.<br><=
/div><div><br></div><div>This template string proposal, in contrast, is =
a more robust way to evaluate expressions inside strings.<br></div><div>=
<br></div><div>Naming aside, it's hard for me to imagine that anyone cou=
ld get these confused with each other.<br></div><div><br></div><blockquo=
te type=3D"cite" id=3D"qt" style=3D""><div>FWIW, I'd love to see an RFC =
on this kind of thing. In particular, I am interested<br></div><div>in s=
eeing what the forms start to look like and what idioms might be improve=
d<br></div><div>or created.<br></div></blockquote><div><br></div><div>Th=
e proposal seems similar in spirit to f-strings in Python, a relatively =
new addition to the language which quickly became one of my favorite fea=
tures. I'm also like to see how it will look in Perl!<br></div><div><br>=
</div><div>Walt</div></body></html>
--301ba8ed5df14c30bdf260cfadda5ad5--
Thread Previous
|
Thread Next