in reply to Re^2: What's happening in this expression? (Updated)
in thread What's happening in this expression?

The debugger is a bad place to play with scoping like this. In effect when you evaluate single lines like this they're more like doing an eval within the scope of the program (more or less; I'm sure someone more familiar with the perl5db could give more specifics). It's kind of like (handwaving) textually shimming in say DebugDump( eval { YOURTEXTHERE } ) into wherever you're looking at and seeing the result.

This means that your my declaration is happening inside of a transient scope (that single eval statement) and then it's going away. Since the my was affecting only $a when you check for defined-ness it fails because the package $a wasn't defined (however your modifications to $x et al changes the package versions of those and the values do persist after the statement). 

$ cat test.pl
use 5.032;
my $foo = 10;
say qq{foo: $foo}
$ perl -d test.pl

Loading DB routines from perl5db.pl version 1.57
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(test.pl:2):      my $foo = 10;
  DB<1> x $foo
0  undef
  DB<2> n
main::(test.pl:3):      say qq{foo: $foo}
  DB<2> x $foo
0  10
  DB<3> my $foo = 20

  DB<4> x $foo
0  10
  DB<5> my $foo = 20; say qq{foo: $foo}
foo: 20

  DB<6> x $foo
0  10

[download]

Simple rule of thumb I tend to follow is just don't use my (or state or our) from the debugger command line to try and affect anything outside of that immediate command line.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Replies are listed 'Best First'.
Re^4: What's happening in this expression? (Updated)
by likbez (Sexton) on Oct 15, 2020 at 04:08 UTC
    You are right. My variables are not always treated correctly, although recently the situation improved. I remember that in the past you just can't work with my variables at all. I just have a utility that stripped my moving them to tail comments and then reversed the situation. But now the usage of my "official" as it is forced by the strict pragma. Which means that such a situation is less acceptable.

    Also if you are using recursion my attribute can't be stripped at all. So this is a clear deficiently.

    That's sad, because IMHO the debugger is the crown jewel of Perl language environment and remains in certain areas unmatched by competition(macros, flexibility of c command, etc.) Possibility of b lineno ($var eq "value") is indispensable for debugging complex programs. That's what I always stress in my Perl advocacy efforts" "Unmatched by competition."

    So any deficiencies here are "highly undesirable."

    That's, of course, raises the question of development priorities...

[reply]
[d/l]
      I remember that in the past you just can't work with my variables at all.

      Lexcial variables (my) were introduced in Perl 5.000, in 1994 - in fact, Perl 5.000's 26th birthday is in two days.

      ... my attribute can't be stripped at all. So this is a clear deficiently. ... the debugger ... is indispensable for debugging complex programs.

      You seem to be implying that the debugger can't handle lexical variables in the programs one is debugging, which is not correct. The debugger, when used as a REPL, has a few limitations - but it's a debugger, not a REPL. If you're looking for REPLs, see e.g.:

[reply]
[d/l]
        While I was unclear, you missed the context:
        I remember that in the past you just can't work with my variables at all. I just have a utility that stripped my moving them to tail comments and then reversed the situation. But now the usage of my "official" as it is forced by the strict pragma. Which means that such a situation is less acceptable.
        I meant in debugger, not in the language
[reply]

In Section Seekers of Perl Wisdom