Mailing List Archive: q, qq and qx here-documents (for consistency with qt here-docs)

q, qq and qx here-documents (for consistency with qt here-docs)

Jan 19, 2024, 1:36 AM

Post #1 of 7 (112 views)

Hi,

The current version of PPC 0019 proposes a here-doc version of `qt`:

> To provide a heredoc version of qt, this:
>
> <<qt{END} TEXT END
>
> will apply qt-like interpolation to TEXT.

Once this is implemented, a nice addition (mostly for consistency and
cuteness) would be to add support for `<<q` (single quotes here-doc),
`<<qq` (double quotes here-doc) and `<<qx` (backticks here-doc).

I note that perlop says:

> Additionally, quoting rules for the end-of-string identifier are
> unrelated to Perl's quoting rules. "q()", "qq()", and the like are not
> supported in place of '' and "", and the only interpolation is for
> backslashing the quoting character.

Adding support for q(), qq() and qx() in place of '', "" and `` to define
end-of-string identifiers (for consistency with the addition of qt() there)
would behave the same as the regular quotes already do in this case, with
the only interpolation being for backslashing the quoting character.

--
Philippe Bruhat (BooK)

The only certain bet in gambling is that it leads to more gambling
(Moral from Groo #11 (Image))

Re: q, qq and qx here-documents (for consistency with qt here-docs) [ In reply to ]

davidnicol at gmail

Jan 19, 2024, 7:49 PM

Post #2 of 7 (111 views)

sorry, but what is qt? Clearly we aren't talking about the graphics library.

On Fri, Jan 19, 2024 at 3:36?AM Philippe Bruhat (BooK) <book@cpan.org>
wrote:

> Hi,
>
> The current version of PPC 0019 proposes a here-doc version of `qt`:
>
> > To provide a heredoc version of qt, this:
> >
> > <<qt{END} TEXT END
> >
> > will apply qt-like interpolation to TEXT.
>
> Once this is implemented, a nice addition (mostly for consistency and
> cuteness) would be to add support for `<<q` (single quotes here-doc),
> `<<qq` (double quotes here-doc) and `<<qx` (backticks here-doc).
>
> I note that perlop says:
>
> > Additionally, quoting rules for the end-of-string identifier are
> > unrelated to Perl's quoting rules. "q()", "qq()", and the like are not
> > supported in place of '' and "", and the only interpolation is for
> > backslashing the quoting character.
>
> Adding support for q(), qq() and qx() in place of '', "" and `` to define
> end-of-string identifiers (for consistency with the addition of qt() there)
> would behave the same as the regular quotes already do in this case, with
> the only interpolation being for backslashing the quoting character.
>
> --
> Philippe Bruhat (BooK)
>
> The only certain bet in gambling is that it leads to more gambling
> (Moral from Groo #11
> (Image))
>

--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

Re: q, qq and qx here-documents (for consistency with qt here-docs) [ In reply to ]

Jan 19, 2024, 8:31 PM

Post #3 of 7 (111 views)

David Nicol wrote:
>
> sorry, but what is qt?
>
> On Fri, Jan 19, 2024 at 3:36?AM Philippe Bruhat (BooK) <book@cpan.org> wrote:
>>
>> The current version of PPC 0019 proposes a here-doc version of `qt`:

PPC 0019:
<https://github.com/Perl/PPCs/blob/main/ppcs/ppc0019-qt-string.md>

"String Literals with Expression Interpolation" aka quoted template.

Discussion from last week:
<https://www.nntp.perl.org/group/perl.perl5.porters/2024/01/msg267671.html>

--
Arne Johannessen
<https://arne.johannessen.de/>

Re: q, qq and qx here-documents (for consistency with qt here-docs) [ In reply to ]

davidnicol at gmail

Jan 19, 2024, 8:58 PM

Post #4 of 7 (111 views)

oh. I don't like it. We already have ways to interpolate arbitrary code
into qq strings, including regex text, by doing stuff like

my $bracketed_foo = "{@{[foo()]}}";

of course that's kind of a "leaning toothpick syndrome" way to do things
but the feature strikes me as gratuitous complexity.

dln

On Fri, Jan 19, 2024 at 10:31?PM <aj22@thaw.de> wrote:

> David Nicol wrote:
> >
> > sorry, but what is qt?
> >
> > On Fri, Jan 19, 2024 at 3:36?AM Philippe Bruhat (BooK) <book@cpan.org>
> wrote:
> >>
> >> The current version of PPC 0019 proposes a here-doc version of `qt`:
>
> PPC 0019:
> <https://github.com/Perl/PPCs/blob/main/ppcs/ppc0019-qt-string.md>
>
> "String Literals with Expression Interpolation" aka quoted template.
>
> Discussion from last week:
> <https://www.nntp.perl.org/group/perl.perl5.porters/2024/01/msg267671.html
> >
>
>
> --
> Arne Johannessen
> <https://arne.johannessen.de/>
>
>
>
>

--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

Re: q, qq and qx here-documents (for consistency with qt here-docs) [ In reply to ]

happy.barney at gmail

Jan 19, 2024, 10:32 PM

Post #5 of 7 (111 views)

On Sat, 20 Jan 2024 at 07:14, David Nicol <davidnicol@gmail.com> wrote:

> oh. I don't like it. We already have ways to interpolate arbitrary code
> into qq strings, including regex text, by doing stuff like
>
>
> my $bracketed_foo = "{@{[foo()]}}";
>
> of course that's kind of a "leaning toothpick syndrome" way to do things
> but the feature strikes me as gratuitous complexity.
>
> dln
>
>
depends on implementation
- qt is focused on scalars to replace pattern ${\ ...) with ${ }
- qt has a chance to eliminate nested escaping (like for example javascript
template literals does)

My main concern is that qt is allowed alongside interpolated strings, so
they can be mixed together.
For consistency of language and maintainability of code base in long time I
believe it has to be feature
affecting interpolation string in whole context where feature is on.

Code like this shouldn't be allowed:
my $foo = qt ( ${ ${\ foo } })

Brano

Re: q, qq and qx here-documents (for consistency with qt here-docs) [ In reply to ]

davidnicol at gmail

Jan 25, 2024, 6:55 PM

Post #6 of 7 (81 views)

there's also Tie::Function, mine on CPAN, which lets you call the sub tied
to the hash using hash syntax, which interpolates.

It's very handy for URL-encoding and such

On Sat, Jan 20, 2024 at 12:33?AM Branislav Zahradník <happy.barney@gmail.com>
wrote:

>
>
> On Sat, 20 Jan 2024 at 07:14, David Nicol <davidnicol@gmail.com> wrote:
>
>> oh. I don't like it. We already have ways to interpolate arbitrary code
>> into qq strings, including regex text, by doing stuff like
>>
>>
>> my $bracketed_foo = "{@{[foo()]}}";
>>
>> of course that's kind of a "leaning toothpick syndrome" way to do things
>> but the feature strikes me as gratuitous complexity.
>>
>> dln
>>
>>
> depends on implementation
> - qt is focused on scalars to replace pattern ${\ ...) with ${ }
> - qt has a chance to eliminate nested escaping (like for example
> javascript template literals does)
>
> My main concern is that qt is allowed alongside interpolated strings, so
> they can be mixed together.
> For consistency of language and maintainability of code base in long time
> I believe it has to be feature
> affecting interpolation string in whole context where feature is on.
>
> Code like this shouldn't be allowed:
> my $foo = qt ( ${ ${\ foo } })
>
> Brano
>
>
>
>

--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

Re: q, qq and qx here-documents (for consistency with qt here-docs) [ In reply to ]

leonerd at leonerd

Feb 1, 2024, 9:46 AM

Post #7 of 7 (61 views)

On Fri, 19 Jan 2024 10:36:49 +0100
"Philippe Bruhat (BooK)" <book@cpan.org> wrote:

> Adding support for q(), qq() and qx() in place of '', "" and `` to
> define end-of-string identifiers (for consistency with the addition
> of qt() there) would behave the same as the regular quotes already do
> in this case, with the only interpolation being for backslashing the
> quoting character.

Those seem like simple enough additions to add alongsite the qt
heredocs yes.

Currently looking at the schedule of things, I don't imagine I'm going
to get any time to work on qt now before v5.40 release so that'll have
to be a thing for v5.42 - or will we call it v7? I can always hope ;)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/