Re^5: Shouldn't references be readonly?

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

Having had a further look at your OP, you seem to be complaining that the scalar ref value should readonly - I was thinking that you were wanting the anonymous array to readonly?

So is the following a correct summary of your position as to how you would like things to work?

[ 1, 2, 3];  # a readonly temporary reference to a mutable anonymous a
+rray
[ 1, 2, $x]; # also a readonly temporary reference to a mutable anonym
+ous array

bless 'Foo', [1,2,3];# a readonly temporary reference to a mutable ano
+nymous array
                     # where the array was mutated by blessing it

$a = [1, 2, 3]; # $a is a rw copy of the temp ro array reference
[download]

Dave.

Comment on Re^5: Shouldn't references be readonly? Download Code

Replies are listed 'Best First'.
Re^6: Shouldn't references be readonly? by LanX (Saint) on Aug 05, 2020 at 18:44 UTC
My complaint is primarily about aliases, where I don't understand why Perl complains about when overwriting an alias to 1 but not one to `[ 1,2,3,$x]` (see examples in my OP especially the update) Both are literal constructs unbound to any named variable. I'm NOT saying that anonymous arrays -ie the content - should be immutable, but their reference. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l]
Re^6: Shouldn't references be readonly? by LanX (Saint) on Aug 05, 2020 at 20:29 UTC
> So is the following a correct summary of your position as to how you would like things to work? after rereading it, yes this follows my mental model. Analog to `1; # a readonly temporary scalar $a = 1 ; # $a is a rw copy of the temp scalar` [download] Of course I could be wrong, but I'm still waiting for someone to understand my question... Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l]
Re^7: Shouldn't references be readonly? (updated) by haukex (Archbishop) on Aug 05, 2020 at 20:49 UTC
I'm still waiting for someone to understand my question... I understand it (I think) `:-)` The difference between `map { $_++ } 1` failing and `map { $_++ } []` not failing, or even `map { $_++ } \1` not failing, is pretty clear to me. I just don't have an answer for you `:-(` With `[]`, I understand the arguments that it's a constructor, for example `sub foo () { 1 }` can be inlined, but `sub bar () { [] }` returns a new anonymous array each time. But something like `map { $_++ } \undef` or `map { $_=3 } \1` not failing doesn't entirely make sense to me yet (note `map { $$_++ } \undef` does fail). ~~As an aside, I was playing around in the console a bit and can't yet wrap my head around this, it feels buggy, but~~ that may just be because it's getting late here: `$ perl -wMstrict -MData::Dump -e 'dd $_ for map { $_++ } \undef' \undef $ perl -wMstrict -MData::Dump -e 'dd $_ for map { ++$_ } \undef' 94067726450329` [download] Update: Nevermind, it clicked, d'oh. Also made a few minor edits to the above. Update 2: Oops, looks like my update came at just about the same time as your reply, sorry.	[reply] [d/l] [select]
Re^8: Shouldn't references be readonly? by Fletch (Bishop) on Aug 05, 2020 at 21:16 UTC
The undef `$_++` vs `$$_++` I think the former is working because what's happening is: An `SVrv` pointing to the `SV` for undef is pushed on the arg stack When `map` calls the EXPR `$_++` that reference is getting numified, incremented, and that new int value stuck back into the `SV` on the arg stack Since it's a postincrement the map is returning the original value of `$_` which is the ref to undef The call stack goes away and with it the `SV` which had the numified address plus one. In the second case you're explicitly dereferencing the `SVrv` to the constant `undef` and trying to increment that* (which fails because `undef` is a singleton readonly `SV`). Edit:* And again yes making explanation by way of the implementation, but I think that's because knowing (sort of) how this is implemented under the covers makes these particular corner cases' behaviors not (as) surprising. The cake is a lie. The cake is a lie. The cake is a lie.	[reply] [d/l] [select]
Re^8: Shouldn't references be readonly? by LanX (Saint) on Aug 05, 2020 at 21:11 UTC
> I understand it :-) I wished I could up-vote you multiple times. :) > but sub bar () { [] } returns a new anonymous array each time. Interesting ... here a workaround `DB<99> my $a =[]; sub bar () { $a } DB<100> sub tst { print bar,bar} DB<101> tst ARRAY(0x3365bc0)ARRAY(0x3365bc0)` [download] But sorry when I insist, the following case should be an error, because the aliased literal array will be destroyed afterwards, which sense does it make to alter it? `map { $_++ } []` I wouldn't mind `map { $_+1 } []` tho. > But something like map { $_++ } \undef not failing doesn't entirely make sense to me yet agreed, I think it's simply not covered. > As an aside, I was playing around in the console a bit and can't yet wrap my head around this, ... is pretty clear to me. I also have an answer for you ;-p The first post -increment returns the original value before incrementing. The second pre -increment returns the result, which is the numification of the reference +1 `DB<105> p []+1 53924433` [download] Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l] [select]

In Section Seekers of Perl Wisdom