Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re^14: ref to read-only alias ... why? (notabug)

by dk (Chaplain)
on Jan 06, 2012 at 22:26 UTC ( [id://946679]=note: print w/replies, xml ) Need Help??


in reply to Re^13: ref to read-only alias ... why? (notabug)
in thread ref to read-only alias ... why?

Sorry, I didn't make myself clear. I do see that these values are modifiable. But my objection is that for(1..3) construct doesn't do aliasing, which is 50% of the original bug. If my example above did print 3 instead of 2, then yes, I'd accept that as a proof.

Same thing on $_++ for 1 - it dies, because of aliasing comes into play. And I neither get what does "intentionally returns a modifiable value (in a sense) some of the times" mean. For what I see, it just doesn't return a modifiable value, at all.

Replies are listed 'Best First'.
Re^15: ref to read-only alias ... why? (notabug)
by ikegami (Patriarch) on Jan 07, 2012 at 01:09 UTC

    But my objection is that for(1..3) construct doesn't do aliasing

    That's not true. Exactly the same aliasing occurs for both for(1..3) and for(1).

    "intentionally returns a modifiable value (in a sense) some of the times" mean

    Intentionally coded to return a value that can be changed without causing a read-only error.

      Exactly the same aliasing occurs for both for(1..3) and for(1).

      I'm sorry, but you're dead wrong here:

      my $a = 2; $_++ for 1..$a; print "$a\n"; # 2 my $a = 2; $_++ for $a; print "$a\n"; # 3
      clearly, there are two different mechanisms: the first does not do aliasing, whereas the second does.

      But anyway, I still don't understand the "working case" you referred to that my patch will break. Could you please produce that?

      Intentionally coded to return a value that can be changed without causing a read-only error.

      Is there any proof of that intention? Best in perldoc?

        clearly, there are two different mechanisms: the first does not do aliasing, whereas the second does.

        How can you claim that for(1..3) doesn't alias when you can clearly see ++$_; having an effect on what it returns?

        In both for(1..3) and for(1), $_ is aliased to each value returned by the expression in the parens.

        I'm sorry, but you're dead wrong here:

        First, your example does not demonstrate a lack of aliasing. It just shows that $_ isn't aliased to $a. That's to be expected, because 1..$a doesn't return $a anymore than 0+$a does.

        Second, you pulled a switcheroo. I said for(1..3) aliases (and proved that it does), but your code uses for(1..$a). for(1..$a) is implemented differently; it's a counting loop and not a foreach loop. It still aliases, though.

        Is there any proof of that intention? Best in perldoc?

        There was code written to specifically perform this effect. By definition, the effect must be intentional.

        my $a = 2; $_++ for 1..$a; print "$a\n"; # 2

        thats a confusing example, nothing else than

        my $a = 2; $_++ for 1..2; print "$a\n";

        I don't understand what it's supposed to prove.

        Cheers Rolf

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (6)
As of 2024-03-29 09:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found