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

What about
my $a=$x=$y=$z = foo()
Here my attribute does not propogate like in case of comma. It applies only to $a, right ?

But now the fun starts

DB<3> use v5.10

DB<4> my $a=$x=$y=$z = 1

DB<5> say "|$a|$x|$y|$z|"
||1|1|1|  
DB<6> unless( defined($a) ){ say "a is undefined"}
a is undefined
why $a remains uninitialized?
  • Comment on Re^2: What's happening in this expression? (Updated)

Replies are listed 'Best First'.
Re^3: What's happening in this expression? (Updated)
by Fletch (Chancellor) on Oct 12, 2020 at 03:25 UTC

    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

    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.

      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...

        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.:

Re^3: What's happening in this expression? (Updated)
by haukex (Bishop) on Oct 12, 2020 at 08:45 UTC
    What about my $a=$x=$y=$z = foo()
    $ perl -MO=Deparse,-p -e 'my $a=$x=$y=$z = foo()' (my $a = ($x = ($y = ($z = foo()))));

    The comma is left associative and the assignment is right associative. See perlop.

    Here my attribute does not propogate like in case of comma.

    No, it doesn't "propagate" with the comma either, as I showed.

Re^3: What's happening in this expression? (Updated)
by AnomalousMonk (Bishop) on Oct 12, 2020 at 01:52 UTC

    That's not what I get nor what I would expect (but this is not in debug mode):

    Win8 Strawberry 5.8.9.5 (32) Sun 10/11/2020 21:47:54 C:\@Work\Perl\monks >perl -Mwarnings my $a=$x=$y=$z = 1; print "|$a|$x|$y|$z|"; ^Z |1|1|1|1| Win8 Strawberry 5.30.3.1 (64) Sun 10/11/2020 21:45:55 C:\@Work\Perl\monks >perl -Mwarnings use v5.10; my $a=$x=$y=$z = 1; say "|$a|$x|$y|$z|"; ^Z |1|1|1|1|

    Update:

    What about

    my $a=$x=$y=$z = foo()
    With respect to this specific statement:
    Win8 Strawberry 5.8.9.5 (32) Sun 10/11/2020 21:48:09 C:\@Work\Perl\monks >perl -Mstrict -Mwarnings use Data::Dump qw(dd); sub foo { return 9, 8, 7; } my ($x, $y, $z); my $a = $x = $y = $z = foo; dd $a, $x, $y, $z; ^Z (7, 7, 7, 7)
    Same result under version 5.30.3.1.


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

Re^3: What's happening in this expression?
by LanX (Cardinal) on Oct 12, 2020 at 07:22 UTC