Re^2: What's going on with either constants folding or B::Deparse output in this case?

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.

Comment on Re^2: What's going on with either constants folding or B::Deparse output in this case? Select or Download Code

Replies are listed 'Best First'.
Re^3: What's going on with either constants folding or B::Deparse output in this case? by haukex (Archbishop) on Feb 25, 2017 at 17:13 UTC
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 ...` [download] 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.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: What's going on with either constants folding or B::Deparse output in this case?
by haukex (Archbishop) on Feb 25, 2017 at 17:13 UTC

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
...
[download]

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.

[reply]
[d/l]
[select]