Skip Menu |
Report information
Id: 123217
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors:
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



Subject: Stringification of qr/(??{<<END})/
Download (untitled) / with headers
text/plain 1.2k
In this code: qr/(??{<<END})/ f.o b.r END The body of the here-doc occurs outside the qr// thing, and, indeed, it interpolates the here-doc body into the regular expression at run time (output after __END__): print "[[[foo\nbar\n]]]" =~ qr/((??{<<END}))/ f.o b.r END __END__ foo bar print qr/(??{<<END})/, "\n" f.o b.r END __END__ (?^:(??{<<END})) But the qr// thing stringifies without the here-doc body. In some ways, this could be argued as correct, since the stringified regular expression contains exactly what the original qr/.../ contained (after interpolation and double-quotish processing), and the bodies of code blocks are kept unchanged. But it causes problems if the regular expression is stringified and evaluated. Normally that’s not a good thing to do with code blocks. But how do you deparse something like this? Should B::Deparse be deparsing regexp code blocks on its own, instead of using the stringified regular expression? Or should we consider this a more fundamental flaw, in that other pieces of code should be able to serialise such regular expressions? Should we mangle the here-doc at compile time and turn it into "..."? This is, in some ways, related to #115256. -- Father Chrysostomos
From: Dave Mitchell <davem [...] iabyn.com>
To: perl5-porters [...] perl.org
Date: Mon, 17 Nov 2014 12:34:39 +0000
Subject: Re: [perl #123217] Stringification of qr/(??{<<END})/
Download (untitled) / with headers
text/plain 496b
On Sat, Nov 15, 2014 at 01:49:59PM -0800, Father Chrysostomos wrote: Show quoted text
> qr/(??{<<END})/ > f.o > b.r > END
(Vomit...) Perhaps we should just insist that heredoc terminators must be within the scope of the sub-parse? I wonder whether that would break anything? (And whether its easy to enforce?) That would presumably also outlaw $s = "$hash{<<EOF}"; foo bar EOF -- Lear: Dost thou call me fool, boy? Fool: All thy other titles thou hast given away; that thou wast born with.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 564b
On Mon Nov 17 04:35:03 2014, davem wrote: Show quoted text
> On Sat, Nov 15, 2014 at 01:49:59PM -0800, Father Chrysostomos wrote:
> > qr/(??{<<END})/ > > f.o > > b.r > > END
> > (Vomit...) > > Perhaps we should just insist that heredoc terminators must be within > the scope of the sub-parse? I wonder whether that would break anything? > (And whether its easy to enforce?)
It would be easy. Show quoted text
> That would presumably also outlaw > > $s = "$hash{<<EOF}"; > foo > bar > EOF
And s//<<FOO/e. I don't think it's acceptable to break that. -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
On Sat Nov 15 13:49:59 2014, sprout wrote: Show quoted text
> In this code: > > qr/(??{<<END})/ > f.o > b.r > END > > The body of the here-doc occurs outside the qr// thing, and, indeed, > it interpolates the here-doc body into the regular expression at run > time (output after __END__): > > print "[[[foo\nbar\n]]]" =~ qr/((??{<<END}))/ > f.o > b.r > END > __END__ > foo > bar > > print qr/(??{<<END})/, "\n" > f.o > b.r > END > __END__ > (?^:(??{<<END})) > > But the qr// thing stringifies without the here-doc body. In some > ways, this could be argued as correct, since the stringified regular > expression contains exactly what the original qr/.../ contained (after > interpolation and double-quotish processing), and the bodies of code > blocks are kept unchanged. > > But it causes problems if the regular expression is stringified and > evaluated. Normally that’s not a good thing to do with code blocks. > But how do you deparse something like this? > > Should B::Deparse be deparsing regexp code blocks on its own, instead > of using the stringified regular expression? Or should we consider > this a more fundamental flaw, in that other pieces of code should be > able to serialise such regular expressions? Should we mangle the > here-doc at compile time and turn it into "..."? > > This is, in some ways, related to #115256.
I’ve decided to forget having the core stringify qr// any differently. If programs really need regexp code blocks to serealise reusably, then they already have more serious problems, like closure behaviour. My particular use case was B::Deparse, and I have fixed that in the commits leading up to b813f4458249d. -- Father Chrysostomos


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org