Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^5: Shouldn't references be readonly?

by dave_the_m (Monsignor)
on Aug 05, 2020 at 18:32 UTC ( #11120338=note: print w/replies, xml ) Need Help??


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

Dave.

Replies are listed 'Best First'.
Re^6: Shouldn't references be readonly?
by LanX (Cardinal) 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

Re^6: Shouldn't references be readonly?
by LanX (Cardinal) 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

    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

      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

      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.

        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.

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

        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

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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11120338]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (3)
As of 2020-10-24 23:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My favourite web site is:












    Results (247 votes). Check out past polls.

    Notices?