http://qs321.pair.com?node_id=11120365


in reply to Re^6: Shouldn't references be readonly? (updated)
in thread Shouldn't LITERAL references be readonly? (updated)

All I can say is that I personally strongly disagree with your use of term "literal" in this context, and I think that any attempt to draw an analogy between 1 and 1 is specious. The former is a literal value appearing in the source code and used as a compile-time constant. The latter is a run-time list constructor.

But regardless of that, there is still the question of whether the reference returned by [] and {} should be marked readonly. I suppose it could be but Larry never thought to do so, and there doesn't seem any point in changing it now.

Dave.

  • Comment on Re^7: Shouldn't references be readonly? (updated)

Replies are listed 'Best First'.
Re^8: Shouldn't references be readonly? (updated)
by LanX (Saint) on Aug 05, 2020 at 21:41 UTC
    > But regardless of that, there is still the question of whether the reference returned by [] and {} should be marked readonly. I suppose it could be but Larry never thought to do so,

    Thanks, at least someone beside Hauke who is not trying to convince me that the issue doesn't exist at all. \o/

    > and there doesn't seem any point in changing it now.

    Well ... catching errors would be an issue, don't you think?

    But like always with old errors, I wouldn't surprised if they became "features".

    After changing, some CPAN modules might break because they did something like

    sub func { $_[0] //= { the_default => "values" }; ... }

    which is a broken approach to default values ...

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

Re^8: Shouldn't references be readonly? (updated)
by LanX (Saint) on Aug 05, 2020 at 21:35 UTC
    (you forgot to put [1] into code-tags)

    > The former is a literal value appearing in the source code and used as a compile-time constant.

    Well a compile-time constant with varying refs? Looks pretty much like just another constructor like [1] to me.

    use strict; use warnings; use Data::Dump qw/pp dd/; use constant a => 1; $\="\n"; print \1; # SCALAR(0xdf00e0) print \1; # SCALAR(0xdef540) print \(a); # SCALAR(0x2a19c70) print \(a); # SCALAR(0x2a19c70)

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      print \1; # SCALAR(0xdf00e0) print \1; # SCALAR(0xdef540)

      I don't understand what of interest that's supposed to show. The first line has a compile-time literal value 1, and a run-time operator, \. The second line has another literal and op. Whether the two literals resolve to the same SV internally is entirely down to how the compiler optimises things. As it happens perl doesn't look for common shared constants.

      (Also as it happens, \1 is constant-folded at compile time, in the same way that 1+2 is.)

        > I don't understand what of interest that's supposed to show.

        The fact that [...] resolves each time to a new AV was used as argument against being literal.

        Obviously most "literals" are not treated the way constants are. (with the exception of undef)

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

      That... is actually a pretty good example.

      Run it through Deparse though, and:

      use strict; use warnings; use Data::Dump ('pp', 'dd'); use constant ('a', 1); $\ = "\n"; print \1; print \1; print \1; print \1;
        > Run it through Deparse though,

        And what do you think that proves?

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery