Front page | perl.perl5.porters |
Postings from June 2022
Re: pre-RFC: template strings
Thread Previous
|
Thread Next
From:
Oodler 577 via perl5-porters
Date:
June 13, 2022 00:49
Subject:
Re: pre-RFC: template strings
Message ID:
YqaJgV62FIrqNY1c@odin.sdf-eu.org
* Walt Mankowski <waltman@pobox.com> [2022-06-12 17:00:46 -0400]:
> 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.
I'm not confusing them per se; and Mark and you were also correctly pointing out *printf related things
(including strftime!) - but in general it's a way of declaring a thing with placeholders regardless that's
to be filled in later by _something_. To be more broad, it's yet another "DSL", among those I also include things like
XS and Perl regular expressions; "languages within the language". My only point is that this would be adding
yet another one, that is all. I wasn't really saying they were related beyond that, but only we might be
able to look at what exists now for direction or inspiration (if any exists). I will reiterate that this
is a declarative thing to be added - which itself requires careful consideration.
Cheers!
Brett
>
> 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
--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Thread Previous
|
Thread Next