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


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

They are all literal reference constructors the content is mutable.

Please compare the analogue situation in JS where [] and {} explicitly documented as "literal".°

See also Readonly which makes the explicit distinction about overwriting a variable holding an array and protecting the deep content.

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

UPDATE

°)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Array

Arrays can be created using the literal notation:

let fruits = ['Apple', 'Banana'];

console.log(fruits.length); // 2
console.log(fruits[0]);     // "Apple"

[download]

Replies are listed 'Best First'.
Re^7: Shouldn't references be readonly? (updated)
by dave_the_m (Monsignor) on Aug 05, 2020 at 21:20 UTC
    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.

[reply]
      > 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" };
    ...
}

      [download]

      which is a broken approach to default values ...

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

[reply]
[d/l]
      (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)

      [download]

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

[reply]
[d/l]
[select]
        print \1;   # SCALAR(0xdf00e0)
print \1;   # SCALAR(0xdef540)

        [download]

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

[reply]
[d/l]

        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;

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom