Skip to content
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

Closed
p5pRT opened this issue Nov 15, 2014 · 6 comments
Closed

Stringification of qr/(??{<<END})/ #14244

p5pRT opened this issue Nov 15, 2014 · 6 comments

Comments

@p5pRT
Copy link

p5pRT commented Nov 15, 2014

Migrated from rt.perl.org#123217 (status was 'resolved')

Searchable as RT123217$

@p5pRT
Copy link
Author

p5pRT commented Nov 15, 2014

From @cpansprout

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

@p5pRT
Copy link
Author

p5pRT commented Nov 17, 2014

From @iabyn

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?)

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.

@p5pRT
Copy link
Author

p5pRT commented Nov 17, 2014

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Nov 17, 2014

From @cpansprout

On Mon Nov 17 04​:35​:03 2014, davem wrote​:

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.

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

@p5pRT
Copy link
Author

p5pRT commented Dec 4, 2014

From @cpansprout

On Sat Nov 15 13​:49​:59 2014, sprout wrote​:

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 b813f44.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Dec 4, 2014

@cpansprout - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant