New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stringification of qr/(??{<<END})/ #14244
Comments
From @cpansproutIn this code: qr/(??{<<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}))/ print qr/(??{<<END})/, "\n" 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 @iabynOn Sat, Nov 15, 2014 at 01:49:59PM -0800, Father Chrysostomos wrote:
(Vomit...) Perhaps we should just insist that heredoc terminators must be within That would presumably also outlaw $s = "$hash{<<EOF}"; -- |
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Mon Nov 17 04:35:03 2014, davem wrote:
It would be easy.
And s//<<FOO/e. I don't think it's acceptable to break that. -- Father Chrysostomos |
From @cpansproutOn Sat Nov 15 13:49:59 2014, sprout wrote:
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 b813f44. -- Father Chrysostomos |
@cpansprout - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#123217 (status was 'resolved')
Searchable as RT123217$
The text was updated successfully, but these errors were encountered: