in reply to Can't coerce UNKNOWN to string in substitution iterator

Hi

Hmm splain has heard of the error (its in perldiag) 

$ cat 2
Can't coerce UNKNOWN to string in substitution iterator at ./coerce.pl
+ line 11, <> line 12.

$ splain 2
Can't coerce UNKNOWN to string in substitution iterator at ./coerce.pl
+ line 11,
        <> line 12 (#1)
    (F) Certain types of SVs, in particular real symbol table entries
    (typeglobs), can't be forced to stop being what they are.  So you 
+can't
    say things like:

        *foo += 1;

    You CAN say

        $foo = *foo;
        $foo += 1;

    but then $foo no longer contains a glob.

[download]

I can't replicate the error in v5.16.1 but I can in v5.18.2

The output starts to differ at line 59 , so I modify the input to just the part that makes error 

5
1 3 8 14 19 26 33

[download]

Adding use re 'debug'; makes it run to completion , but output is not identical

Now looking at the regex, and checking perlre,

I see you're using (??{}) , but the return value (a regex pattern) is either X or nothing ... and there is no X in the input,

so I switch to using (?{}) where return value isn't a regex pattern, and with this change both versions of perl produce the same output

Now its not the same output as before with (??{}) but I dont think thats important

Replies are listed 'Best First'.
Re^2: Can't coerce UNKNOWN to string in substitution iterator (splain, (??{}))
by Anonymous Monk on Oct 10, 2016 at 21:31 UTC
    I think the X is to prevent the regex from matching. Isn't there a better way to do that?
[reply]

      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 (?{

      Read more... (2 kB)

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

      NUMBERS:[1:33
]

      [download]
      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)'

      [download]
      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 (?{

[reply]
[d/l]
[select]
        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:  <%-{-{-{-<

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom