in reply to Re: Can't coerce UNKNOWN to string in substitution iterator (splain, (??{}))
in thread Can't coerce UNKNOWN to string in substitution iterator

I think the X is to prevent the regex from matching. Isn't there a better way to do that?
  • Comment on Re^2: Can't coerce UNKNOWN to string in substitution iterator (splain, (??{}))

Replies are listed 'Best First'.
Re^3: Can't coerce UNKNOWN to string in substitution iterator (splain, (??{}))
by beech (Parson) on Oct 11, 2016 at 00:19 UTC

    Hi

    I think the X is to prevent the regex from matching. Isn't there a better way to do that?

    That is a good observation

    Maybe, there are http://perldoc.perl.org/perlre.html#Verbs for that, more on this at the end of this post

    Taking a second look at output of (??{ versus (?{

    As you can see all three versions end the final result of

    NUMBERS:[1:33 ]
    they just get there by different order of add/delete, not sure how important this is

    Only the crashing/buggy version returns something different when its able to complete under -Mre=debug

    Now back to verbs, using

    $2 - $1 <= $c ? '(*FAIL)' : '(*ACCEPT)'
    makes it fail in the exact same way, which is not too surprising

    Using *PRUNE or $2 - $1 <= $c ? '(*SKIP)' : '(*ACCEPT)' and its just like using (?{

      Now back to verbs, using
      $2 - $1 <= $c ? '(*FAIL)' : '(*ACCEPT)'
      makes it fail in the exact same way ...

      WRT Special Backtracking Control Verbs (in Perl version 5.10+): Rather than using  (??{ ... }) to dynamically compile a  '(*FAIL)' or  '(*ACCEPT)' string into the regex, it may be advantageous to use the
          "(?(condition)yes-pattern|no-pattern)"
      or
          "(?(condition)yes-pattern)"
      conditional expression constructs; they're generally a bit faster and IMHO much more clear.


      Give a man a fish:  <%-{-{-{-<

        Hi

        ... it may be advantageous to use the ...

        :) let me know how it goes :D