develooper Front page | perl.perl5.porters | Postings from November 2014

[perl #123217] Stringification of qr/(??{<<END})/

Thread Next
From:
Father Chrysostomos
Date:
November 15, 2014 21:50
Subject:
[perl #123217] Stringification of qr/(??{<<END})/
Message ID:
rt-4.0.18-9152-1416088199-94.123217-75-0@perl.org
# New Ticket Created by  Father Chrysostomos 
# Please include the string:  [perl #123217]
# in the subject line of all future correspondence about this issue. 
# <URL: https://rt.perl.org/Ticket/Display.html?id=123217 >


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


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About