Skip Menu |
Report information
Id: 124524
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: davidnmfarrell [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [BUG] `<$subrule>` does not cache the compiled subrule (Or bogus test?)
Download (untitled) / with headers
text/plain 1.1k
The <$subrule> syntax is in fact implemented now in Rakudo. The test failure is (supposed to be) for not caching the compiled form of the string $subrule between calls. This is the relevant excerpt from S05: In any case of regex interpolation, if the value already happens to be a Regex object, it is not recompiled. If it is a string, the compiled form is cached with the string so that it is not recompiled next time you use it unless the string changes. (Any external lexical variable names must be rebound each time though.) However, the test seems suspect to me. This is a golfed version of what it does: my $counter = 0; my $subrule = '{$counter++}.'; 'a' ~~ /<$subrule>/; 'b' ~~ /<$subrule>/; is($counter, 1, 'string value was cached'); It fails because $counter ends up being 2 instead of 1. But why should it be 1? The expression `$counter++` is not executed when the subrule is compiled, but each time it is called. I'm not sure how a correct test for the caching feature quoted from S05 above, would even look like. It seems to be intended as a pure performance optimization, rather than something that would change the behavior compared to not doing the caching.
Download (untitled) / with headers
text/plain 362b
Ok, I came up with the following test to replace the existing one: my $counter = 0; my $subrule = (class :: is Cool { method Str { $counter++; '<alnum>' } }).new; 'a' ~~ /<$subrule>/; 'b' ~~ /<$subrule>/; is $counter, 1, 'string value was cached'; It passes on current Rakudo, so I guess it already implements the correct caching behavior.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org