Front page | perl.perl5.porters |
Postings from June 2022
Re: pre-RFC: template strings
Thread Previous
From:
Elvin Aslanov
Date:
June 12, 2022 20:35
Subject:
Re: pre-RFC: template strings
Message ID:
CAJ4KP=13_YA7z2CXcEngh874Js24_RYT_eJxV2m0nX3dmYWOUA@mail.gmail.com
Good,
$`shell command` can also be added to the list
eg. "kernel: $`sysctl kern.bootfile`" (on FreeBSD)
Thanks
On Sun, Jun 12, 2022 at 11:10 PM Oodler 577 <oodler577@sdf-eu.org> 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?
>
> 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.
>
> Cheers,
> Brett
>
> > --
> > rjbs
>
> --
> --
> oodler@cpan.org
> oodler577@sdf-eu.org
> SDF-EU Public Access UNIX System - http://sdfeu.org
> irc.perl.org #openmp #pdl #native
>
Thread Previous