in reply to What's going on with either constants folding or B::Deparse output in this case?

I am not an expert on this, but I do think I have an idea of what's going on: AFAIK the state that m//gc keeps is attached to each string (pos). See the output of the following, just your test cases with debugging added:

use warnings; use strict; use Carp; use Devel::Peek; sub parse { Dump $_[0]; ${$_[0]}=~/\Gfoo/gc or confess; } warn "##### Case 1 #####\n"; parse \(''.'foo') for 1..2; warn "##### Case 2 #####\n"; parse \('foo') for 1..2;

In "Case 1", the dot operator (concat) appears* to create a new string on each execution of the loop. In "Case 2", the same string (same memory address etc.) is passed to the function each time, so m/\G.../gc keeps its state, and so the second call fails.

As for B::Deparse, from its docs:

The output of B::Deparse won't be exactly the same as the original source, since perl doesn't keep track of comments or whitespace, and there isn't a one-to-one correspondence between perl's syntactical constructions and their compiled form, but it will often be close.

* Update: Added the "appears to", since my further investigation below has made me uncertain as to what is going on the exact technical explanation is.

  • Comment on Re: What's going on with either constants folding or B::Deparse output in this case? (updated)
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: What's going on with either constants folding or B::Deparse output in this case?
by vr (Curate) on Feb 25, 2017 at 12:40 UTC

    I understand (at least I think so) why my 1st command line (your "Case 2") dies. I also understand there's no "one-to-one correspondence" between source and B::Deparse'd output (e.g. or die vs die unless). But, then I don't understand why constant folding doesn't work as expected.

    About Devel::Peek output, I see there are Readonly flags in "Case 2" but not in "Case 1". Is that the reason for demonstrated behavior? Can I count on this 'fix' (e.g. prepending an empty string) to parse a hard-coded string several times, if a 3d party module uses similar (as shown) mechanism for parsing? (maybe I'm asking too much here)

    Update. ... So, answering my last question, better not to count on this behavior, but "add more lines of code" such as dummy variable

    Update 2. Deleted, from update above, what was probably speculation and wishful thinking. Still unclear, what's going on.

      I don't understand why constant folding doesn't work as expected.

      I'm not an expert on the Perl internals, for now I'm just drawing my conclusions from the documentation and the debug output. All I can offer at the moment is the output of B::Concise, I have trimmed it down to only the relevant differences between the two:

      $ perl -MO=Concise -we 'sub parse{${$_[0]}=~/\Gfoo/gc or die} parse \( +""."foo") for 1..2' ... a <1> srefgen sKM/1 ->b - <1> ex-list lKRM ->a 9 <$> const(PV "foo") sPRM/FOLD ->a ... $ perl -MO=Concise -we 'sub parse{${$_[0]}=~/\Gfoo/gc or die} parse \( +"foo") for 1..2' ... 9 <$> const(IV \"foo") sM/FOLD ->a ...

      The way I interpret that is that in the first case, the constant ""."foo" is apparently folded down to "foo", however what apparently isn't folded is taking a reference to that string. "Constant Folding" in perlop only talks about the constant folding of strings and numeric values, so I'm sorry I don't have a very solid explanation of why the two examples are different (other than my above interpretation of the concat op, which no longer seems to fully accurately explain the situation).

      In general, I would try to find a solution that doesn't depend on internals like whether certain optimizations were performed or certain internal flags like Readonly are set.

      Can I count on this 'fix' (e.g. prepending an empty string) to parse a hard-coded string several times

      If the problem is that you want to reset m/\G.../gc matches, then what you can do reliably is pos($string)=undef; to reset that particular state, I posted an example here.